Standalone modules w/ source map support

[mojodna]

(For discussion)

For inclusion using require/import + npm-style dependency resolution (which can't assume a transpilation step, hence the use of babel in a prepublish script (which also runs after npm install, potentially obviating the need to include dist/ in git)).

NOTE: this doesn't actually work due to direct require()ing of SASS:

> var main = require("./es5/main")
Error: Cannot find module './style.scss'
    at Function.Module._resolveFilename (module.js:337:15)
    at Function.Module._load (module.js:287:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (../../src/charts/D3ReactBase.jsx:2:60)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)

It's also possible that the use of source-map-support may cause problems in non-V8-based browsers.

[mojodna]

If components are to be imported individually, this probably needs to be in each entrypoint.

[ericsoco]

The story behind each component importing its style.scss: it was an attempt to allow CSS for each component to be bundled with the component, so the consumer would not have to deal with explicitly importing any component CSS.

I'm not sure where this all ended up. @sconnelley could probably say more.

[mojodna]

If we're publishing "build ingredients" to be require()d into apps, we could similarly include SCSS in the package and assume that consumers will include it in their Sass build using @import "~panorama/scss/whatever";. (~ reaches into node_modules)

[ericsoco]

@mojodna we were trying to avoid the additional requirement of having to manually @import component CSS (Sass), especially with the hurdle of specifying a path into node_modules. Ideally there is a very simple way to bring in styles only for the components used in a given application.

Since require / import are JS-specific, I guess it doesn't make sense to think that will be all that's required (and that a build tool like Browserify or Webpack can pick up whatever is in the dependency tree from that). But maybe we can at least have just one place to specify all the Sass requirements.

Is there a way to make a build step that 'sees' which modules are in the dependency tree, from Browserify/Webpack, and concatenates their .scss files as part of the Sass-CSS step? I know how to do the latter half with gulp; I don't know how to access the list of requirements though.

[ericsoco]

Browserify has --list, which outputs the list of deps; might be able to parse that to find which @panorama/toolkit modules are required and then pull in their .scss files in a subsequent Sass -> CSS step.

Looks like webpack has similar functionality (via profile?) tho I'm not quite sure how to get at the deps specifically. The webpack analyzer must do this, though, to create those network graphs.

[mojodna]

@mojodna we were trying to avoid the additional requirement of having to manually @import component CSS (Sass), especially with the hurdle of specifying a path into node_modules. Ideally there is a very simple way to bring in styles only for the components used in a given application.

This is a one-liner, no?

Is there a way to make a build step that 'sees' which modules are in the dependency tree, from Browserify/Webpack, and concatenates their .scss files as part of the Sass-CSS step? I know how to do the latter half with gulp; I don't know how to access the list of requirements though.

Sounds like a webpack plugin (or loader, though I'm not sure it has access to the necessary stuff) could be in order, if one doesn't already exist and we decide that we need webpack.

This seems complicated though.

[ericsoco]

It's a one-liner for each module that needs to import styles, and an easy one to miss. Until I got used to using Leaflet, I would always forget to bring in the styles and then the tiles would be all in the wrong place on-screen. I can imagine a similar situation with Panorama. Anything we can do to ease use for first-timers will make a big difference, since first impressions matter a lot with new libraries.

Of course, there's a limit to how much effort we can/should put into this. Maybe we punt, since our time is limited at this point. Some initial investigation seems worthwhile though, at least a spike to determine how much work it would be to automate importing styles for dependent modules. IMHO.

(And of course saying that puts the ball in my court 😉)