Run transform on submodules?

I’ve done npm install highlight.js and now when I require('highlight.js/styles/default.css') the cssify transform doesn’t come into play.

Is this because default.css is in a sub-module of highlight.js (which is located in node_modules)? I tried making cssify a global transform, but this messes up dependencies of my application that already rely on cssify.

It seems to me like the solution is to fork highlight.js, make a PR, and publish the new version on npmjs.org under a temporary name. I want to avoid all this if possible.

Is there a way to apply cssify to any files required in my application, including submodule files, without breaking dependencies like global transform currently does? If not, this would be nice. It’s intuitive to install cssify then expect it to work on a CSS file required in an application, regardless of where the CSS file is located.

[woodcoder]

I’ve found exactly the issue that @nmn describes of wanting to use modules but increasingly discovering that they’re targeting ES6 and either don’t publish an ES5 version or a suitable browserify transform directive in the package.json.

I’ve written a very naive implementation that allows submodule overrides: https://github.com/substack/module-deps/compare/master...woodcoder:submodule-transform

This looks for a dependencies key in the package.json:

"browserify": {
  "dependencies": {
    "js-csp": {
      "transform": ["babelify"]
    }
  }
}

that will apply to submodules.

The intended implementation will completely replace any transforms in any matching submodule (but still respect global transforms). It should also work on a ‘first wins’ basis, such that on a top-down walk of the dependencies the first override is the only one that gets used. Also if the module is reached before any overrides are set, none can subsequently be applied, for consistent treatment of each module.

I’m not sure that I’ve fully appreciated how the tree walk works, hence I haven’t submitted a pull request, but it’s working well for my situation and hope it’s useful to others.

[dantman]

@terinjokes While that might be ideal, I don’t think that’s going to scale to absolutely everything. There are inevitably going to be some packages that just will not play nice and do things themselves that we need for browserify to work with their package. And acknowledgement and acceptance of this fact is why the browserify ecosystem has things like browserify-shim, debowerify, and more, and why browserify is so powerful.

Some packages may have intermittent maintenance and trying to get them to change something may be unreliable. Some libraries may be written by big organizations that make suggesting changes that only help a few users hard. Some packages won’t want to maintain their own builds just for browserify users. And either won’t want to bother adding some “cruft” to their package.json that only matters in one environment; or will loathe the idea that either browserify plugins become deps for non-browserify users or will behave in some sort of silent peer-deps that must be manually installed at a higher level or may even create version conflict.