4 ms·
You’re right, this is happening to some degree with Parcel. Our aim with Parcel 2 is to open up the plugin system to allow more extensibility while keeping it a
by devongovett 7y ago
You’re right, this is happening to some degree with Parcel. Our aim with Parcel 2 is to open up the plugin system to allow more extensibility while keeping it as simple as possible to use out of the box. This is accomplished through a very well defined plugin system with explicit extension points for each step of the build pipeline (not the Wild West of extensibility like other tools), and a good default configuration that you can extend or override as needed with a simple JSON config format. The result is that you get everything Parcel 1 could do and more out of the box, but you can easily change or extend Parcel 2 with more features specific to your app if you need to.
We’ve been working on Parcel 2 for almost 2 years now (~1 year in design, another in development) and I think it strikes a pretty good balance. I’m excited to see what the community does with it! :)
- ironmagma 7y agoCan the configuration have strong types (via TypeScript or similar) pretty pretty please? One of my main frustrations with webpack is the undocumented, unpredictable, unspecified config file format that seems to have no rhyme or reason, which you must often change with every new plugin you add.
- Sawamara 7y agoI feel that pain, yeah. On the other hand, at least the error messages are often helpful with Webpack.
- devongovett 7y agoYep! I think we should be able to publish a JSON schema definition that editors like vscode can use to provide autocomplete etc.
- orf 7y agoThat’s not strong typing, that’s automated (and not necessarily up to date) documentation :(
- devongovett 7y agoIs there another way to provide strong types for a JSON file? I believe vscode uses schemas from http://schemastore.org/ http://schemastore.org/ for many config files already.
- orf 7y agoIt wasn't clear until now that the configuration is done through JSON rather than being configurable through code (i.e TypeScript). Urgh, JSON for configuration. That's going to be horrible.
- devongovett 7y agoJSON is much more static and predictable for configuration. Config through a real programming language was a mistake that many tools made unfortunately. Static configuration has several nice properties including cacheability and simplicity that cannot be guaranteed in a full programming language. Just look at webpack.config.js for an example of the opposite.
- orf 7y agoThat's all totally awesome and cool, right up until the moment you want to add a comment to your configuration. Because you know, it's configuration, and that requires comments. Quite a few tools went from just JSON configuration files to supporting both .js and .json. Regarding caching, perhaps I'm mistaken but what's the issue there? Two JSON documents can be equivalent with different bytes so you need to re-parse the configuration file fairly often anyway. So what's the difference with just re-evaluating a .js configuration file and caching the output? If someone wants to put a `if (random() > 0.1)` statement in their config then that's their problem.
- hoten 7y agojsonp
- 7y ago