CLI bundler #2618
CLI bundler #2618
Conversation
|
@RunDevelopment is it possible to support both development and minified versions as output? |
We could bundle up the cli into a single file with something like ncc.
I'm not opposed per se but it is code we'll have to maintain for questionable value. You think there are a lot of people who'd find this useful? It's not a huge savings over downloading it from the site, and if you're going to run this from the command line several times, you'd be better off just installing it from npm and bundling it, I think. |
That looks REALLY good!
Hard to say. It does make some things easier (e.g. updating Prism bundles) but idk if people will use it.
The "bundling it" part is the problem. Bundlers don't know in which order Prism's files have to be loaded because their dependencies are declared in |
|
I used ncc. We now have a |
My thinking is, as a PrismJS consumer, if I'm going to download Prism as a one-off, I will use the download page, but if I'm going to need to keep it updated over time, I'm going to use a bundler + npm and can use the babel plugin. I feel like the CLI sits in a space between "spinning up a quick project to play around with" (use the download page) and "building a serious application" (use the babel plugin) that isn't going to get much use. |
|
How about "building a serious application without babel"? We already had issues from people that don't want to use babel. CLI is a nice solution for those people. But it's not like I don't get what you mean. In the worst case, this CLI will be something that gets basically no usage but we still have to maintain it. The reason why I want to somewhat push CLI is that it could be a potential solution for issues like #2617. |
This could very well just be my bias, but... does anyone do this? Even looking at the "people aren't importing things correctly" issue, the user would be using ESModules, and I don't know how many people are using ESModules for serious applications without a bundler, at which point including babel is fairly straightforward. |
|
Well, with ES6+ features and ESModules coming close to being universally supported, there are fewer and fewer reasons to use Babel with each passing year. Projects with TypeScript don't need Babel. Projects with bundlers don't need Babel. I think that the main reason Babel is still so popular is that there is a small framework called React with nice custom syntax. It's the only reason I use Babel but I mainly do things in TypeScript, so things might be different on the JS side. |
Given that the language will continue to evolve faster than the long tail of browsers will add support, I don't think this is true. My team could not easily figure out the exact set of syntax features we can use given our intended browser matrix. However, we can easily configure babel to either figure that out for us or transpile everything down to es5 lowest common denominator (which will be the case for any team that still supports IE11). This allows us to adopt new JS features as they get added to the language rather than when they're adopted by all our supported browsers. I expect this to be the case for a large number of teams for quite a while, React projects or otherwise, and I think this will be a feature of the ecosystem for the foreseeable future.
This could be true, but I think at the point where you've got a bundler set up, and you want to integrate Prism, is it easier to integrate babel + the plugin or to integrate the CLI? I don't think configuring babel is significantly more work than setting up most bundlers in the first place (e.g. parcel is zero-config for babel), and you get to maintain your version through a system you're already using (package.json) rather than adopting an external mechanism for keeping your Prism version up-to-date (CLI). Another thought: there's also a bit of ecosystem complexity involved in providing a third mechanism for consuming Prism. Instead of comparing the download page + babel plugin, you also have to consider the CLI and decide between them. |
|
I find your "ecosystem complexity" argument convincing. While I wouldn't mind third-part tooling (is the babel plugin thrid-party? Are you a third party @mAAdhaTTah???????? ;) ), I also think that it would be a bit of a problem if Prism provided X many ways to do essentially the same thing. The problem is that Maybe we should move towards stabilizing |
lol but on a serious note, I've actually wondered if it makes more sense to move the babel plugin into the PrismJS org, considering it's officially recc'd in the docs.
The babel plugin is one of those, and we created an API for that ( I don't necessarily mind stabilizing |
I don't really have strong opinions on this. The babel plugin would appear more official in the organization, I guess, but that's about the only argument I can see for moving it.
That is probably the best solution but the name
(Looking at third-party libraries, it would also be good to be able to get the title and aliases of components as well.) IMO, implementing those features as free functions in new Components(require('components.json')).listAll("languages") // => ["markup", "css", ...]One problem with this class is that the |
Yeah, there's an "official blessing" aspect to it joining the org proper. It's not super important, so we can revisit it later.
Could you elaborate on why? I think if we're requiring consumers to pass |
Uhmm. We are currently doing exactly that with We could also use |
|
lol well guess I can toss that principle out. Can we hang the functionality we want off that |
|
The idea was to move Also, I just thought of a little trick to implement all of this in a backward-compatible way. The public interfaces of // components.js
var components = {}; // something
module.exports = components; // dependencies.js
function getLoader(components, load, loaded) { ... }
module.exports = getLoader;With an intended usage like this: const components = require('components.js');
const getLoader = require('dependencies.js');
const loader = getLoader(components, load, loaded);How about we change it to this: // components.js
class Components {
getLoader(load, loaded) { ... }
// other functions (e.g. listAll, getTitle, etc.)
}
var components = new Components({ /* the JSON from `components.json` */ });
module.exports = components; // dependencies.js
function getLoader(components, load, loaded) {
console.warn('Deprecated! Use `components.getLoader` instead.');
return components.getLoader(load, loaded);
}
module.exports = getLoader; |
|
An ESM-based module system for languages and plugins is planned for v2 completely eliminating the need for this. I'll close this now. |
This resolves #2404.
I added a small CLI bundler that is functionally equivalent to the download page. It can be used like this:
npx prismjs bundle --languages=html,java,php --theme=coy --js-out=prism.js --css-out=prism.cssAPI of the CLI:
Aside from Prism's files, it has 2 additional dependencies:
This is a problem. I incorrectly installed them as dev deps for now so that Prism still has 0 hard dependencies. I don't know what the best course of action for this is.
There's also the question where we even want a CLI for Prism. (I think it would be nice.)
Some input would be nice.