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! :)

Can 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.

Yep! I think we should be able to publish a JSON schema definition that editors like vscode can use to provide autocomplete etc.

That’s not strong typing, that’s automated (and not necessarily up to date) documentation :(

Is there another way to provide strong types for a JSON file?

I believe vscode uses schemas from http://schemastore.org/ for many config files already.

Yep, a schema would work fine for this (and you can generate it from types)

You can test them locally using vscode using the "$schema" field on the root obj, here's an example PR doing all that: https://github.com/danger/peril/pull/281

You can either have users add that schema reference in the JSON (throw it in the template) or ship a vscode extension which connects them

If you define the types in TS, you can use https://github.com/YousefED/typescript-json-schema to automatically generate a JSON schema from it. That way, configurations can be specified either in an executable JS module or in a JSON file.

Yep, we’ll definitely use a tool like that. We already have types in Flow for all of Parcel 2, so should be possible to do something similar.

It 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.

JSON 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.

All configuration is static. The advantage of using JS (or a language file) is that you run it to generate the appropriate config for that moment and environment.

That need won't ever go away, so not supporting means we're back to users generating their own "static" config files in a separate process. Nothing has been saved, only made more complicated.

That'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.

We use json5, which allows comments.

You cannot statically cache the results of a .js file - it might include objects or functions that cannot be serialized, and might cause side effects that parcel cannot know about. If we supported .js config files, we would have to intentionally limit what you can return to basically just JSON, so you wouldn’t get much benefit from it and it would be hard to enforce.

Oh right! Thank you for your clarifying comments, this does sound pretty interesting. Sorry for being flippant before.

Looking forward to reading about the new release!

jsonp

I feel that pain, yeah. On the other hand, at least the error messages are often helpful with Webpack.

While I think this cycle is real, I feel Parcel has done a good job in general being very careful about becoming what they aimed to avoid. Sure, Parcel has some feature creep, but I’d say they have pretty much completely accomplished the goal of removing the need for complicated Webpack configs.

Is it practical? Apparently it’s practical enough that it can compile Monaco Editor, which can either use a fairly hefty Webpack config, or no config at all with Parcel.

While it is a cycle, it isn’t necessarily a bad cycle. With this cycle there is constant innovation to meet changing needs; there is always some new product addressing the shortcomings of the incumbent competitor.

One bad thing about the cycle is we never get to stop dealing with the problem. Because we’re in a cycle of destruction and renewal, applications rot as the infrastructures under them become incompatible.

Where people stopp trying to make “pluggable systems” and “platforms” and instead tried to actually solve problems with finality, and to create procedural interfaces that cover a clear cone of responsibility, the result is mature libraries that stop changing, and become bedrock under applications.

I won’t say it’s “bad” not to strive for that. It is a unique challenge you may or may not wish to tackle.

One person’s bedrock is another person’s pile of anachronisms, cruft, and poorly designed abstractions held together with duct tape.

Bedrock in this sense is small tools that you either build on or you don’t.

What you’re describing is different:

“Abstractions” are by definition unnecessary, they are imaginary things which imperfectly model of some real things underneath. They are contrasted with control systems, which strive to manipulate those things without any metaphor.

“Cruft” is items which you don’t need that are bundled with items you do need. It is contrasted with tools that are easy to just not use at all.

I don’t know what anachronism means in this context.

I’m not saying it’s easy to make tools that are neither abstract, nor bundled with unrelated things. Just that it is a place you can aim for.

I disagree with your notion that abstractions and cruft are inevitable. They’re not inevitable, they are encouraged in the present development climate.

Personally, I take the “run everywhere the same” aspect of web sites very seriously, so I don’t think bleeding edge browser features are an important part of the solution for me.

I also don’t think “build pipelines” are part of the solution.

But I do support you pursuing your vision of finality. Mine is pretty different, you can look up “browser bridge” on NPM if you are interested.

Every widely supported feature was once a bleeding-edge feature.

I'm not sure how you can about finding fundamental enduring solutions to platform gaps that user-space tools solve without adding platform features. That's always going to create a period where some browsers support a feature and some don't, and we've _always_ had to deal with that. It won't be different here.

I mention build pipelines because that's what most bundlers actually are. If they drop the bundling part, they can just focus on that.

I think platforms “mature”, and nothing important happens after that. The web was mature around the time WebGL was widely adopted. Bundles don’t do anything we can’t already do. They just make the web more brittle.

Which means: lovely for you, until something snaps.

For me that’s two cons: lost users, and a more complex data model. And no pros.

The way things are going it suffices that Chrome and Safari do it.

I really hope that by separating Web Bundles from signed exchanges that Firefox will get on board. And I really hope that Firefox retains and gains relevance somehow.

That doesn't hold up with browserify => webpack though. Webpack came after Browserify, offered more features, but it was a pain to configure and had no sane defaults. It was still widely adopted and was preferred over the older, much easier to configure browserify, because of its flexibility.

Parcel's been around for well over a(two?) year(s) now and actually instigated a lot of change and refinement in the bundler market. Most now have zero-config options available, either as a result of Parcel coming on the scene, or with inspiration from it.

Thank you for bringing up how new Parcel is. It'll be interesting to see how we as an industry manage ten year old legacy projects built on top of nodejs/js.

You know, when there's a sudden request for a new feature in a project that's been ticking along for five years - and you need to install a development environment to add said feature - but the build system has been abandoned for three years...

Seems that Prettier.js has been able to hang on step 4 and almost avoid 5 and 6 (so far) :-)

I think that is precisely what makes it so desirable in any project, no more organizational fighting about insubstantial stylistic matters.

I would love that ClangFormat was the same. If you leave the door open to interpretations, interpretations will enter the room.

This is generally true and I've seen it happening again and again. One of the exceptions (IMHO) that goes a bit the other way is Create React App. That's partially why I like it so much. It has become even simpler to use for the easy usecases. There's tutorials to do many of the complicated things, and you can always eject, but if you don't have convoluted needs it works very smoothly.