Parcel: Parcel 2: Supports in-repository plugins

[arcanis]

🙋 Feature request

The current validation doesn't support relative or absolute paths, which means that in order to make a plugin one has to put them into their own subdirectory and use the link: protocol (or publish it to npm).

💁 Possible Solution

The validation should be tweaked to be ignored if the path starts with ., ../, /, or returns true for path.isAbsolute.

[jamiebuilds]

I understand exactly why this is desired. But this was actually an intentional design decision.

To explain why, let me explain what happened with the Babel ecosystem...

When we designed the Babel plugin API, all we really cared about was an entry point to the plugin, specifying a plugin was literally just the node module resolution API.

However there were two big problems with this:

1. The highly dynamic nature of how plugins/presets get resolved in Babel makes it effectively impossible to ever do caching well in any sort of automatic way.
2. Because people could put plugins wherever they wanted, 99% of the Babel ecosystem is actually not in packages. The vast majority of Babel plugins are actually internal to companies sitting in random folders, or buried in other tools like Jest.

Both of these were really bad outcomes for Babel. Performance is made significantly worse by not having great caching, and not having plugins in packages has cause the ecosystem to miss out from a lot of great contributions. Not having plugins in packages has also caused a lot of people to have really messy build systems around Babel that make it hard to upgrade over time, primarily because they aren't versioned.

In Parcel we have a chance to do things differently. We want to learn from past mistakes in tools like Babel (which are partially my fault).

So in Parcel we've decided (so far) that plugin specifiers = names of versioned packages because:

1. It makes cache invalidation significantly easier -- We can rely on the package version unless it is symlinked in which case we also know that it's being worked on and we can watch it
2. It helps grow the Parcel ecosystem -- By forcing everyone to create packages, they are only 1 step away from open sourcing it and contributing back.
3. It helps keep our user's codebases cleaner and more maintainable over time -- They can version their Parcel plugin alongside Parcel versions and upgrade their codebases more incrementally.

I know that this comes at the cost of forcing plugin authors to learn what packages even are or how to develop packages. But I think going through that process will help them build better plugins (and gain transferable skills in the process).

It's not the most convenient thing we could do, but Parcel is trying to clean up a lot of what the JavaScript bundler toolchain has been doing the last several years. The good news is that these sorts of restrictions are easy to relax later, but if we didn't start with them we wouldn't be able to add them in later.