Closed slonoed closed 5 years ago
I think the plan was to start using JSX and ES6 in the source code soon, at which point it would be crucial that the standard entry point is the result of the build step. Any comments on this, @bebraw?
@odf at this point var React = require('react');
must be excluded from build (and any other peer deps)
I'm not sure what you mean. My assumption had been that declaring React as external in the Webpack configuration would take care of this. But I admit I haven't looked much into these things.
I think the plan was to start using JSX and ES6 in the source code soon, at which point it would be crucial that the standard entry point is the result of the build step. Any comments on this, @bebraw?
Yeah, that is the reason why main
points at dist
. This allows you to use whatever tech you want within /lib
. The distribution build contains an UMD wrapper generated by Webpack. This means that it will work within CommonJS, AMD and global environment. React is resolved as an extern (not included in the build) so I don't see require('react')
being a problem. The wrapper deals with that.
This change will be help in debug time. Because we will be able to see separate files in debugger.
Would it help if we generated source maps?
Alternatively you count point at plexus-form/lib
during development though that will can get slightly problematic when JSX etc. is used there.
+1 for source maps.
Ideally you would have a minified bundle for plain <script />
usage, a jsx-transformed full tree lib for node-style require usage (published on npm), and the original source tree for development.
The second is not really possible via webpack as far as I know, but would be the preferred distribution for other node-style packages requiring plexus-forms. They would have their own bundling and minifying process (which would work with minified bundles, but would work better with the plain JavaScript source tree).
We face the same situation for a reusable package using webpack (which I'm very happy with otherwise).
About sourcemaps, in case you want to try it out, set
{
devtool: 'source-map',
...
output: {
sourceMapFilename: '[file].map'
...
}
}
a jsx-transformed full tree lib for node-style require usage (published on npm)
Yeah. This is a difficult one with Webpack. I guess you would have to handle this case separately somehow. It gets even more complicated once you integrate Babel's ES6 features and such. I'm interested in hearing how people deal with this case.
I agree it would be ideal for Node distribution.
It's not particularly hard to clone a tree of source files and run a transformation on each. There's no need to do that with webpack, as each file would be processed separately. If Unix-only is okay, a shell script would probably be the fastest way to implement this, but I'm sure we could also do it in node with relatively little pain. If you're interested, I can create a branch for experimenting with this kind of thing.
@odf I experimented with this on some work of mine. Apparently it's really simple to do. Try:
"prepublish": "babel ./lib --out-dir ./dist-modules"
to package.json
scriptspackage.json
to "main": "dist-modules/index.js",
.gitignore
dist-modules
. We'll want to include that for NPM distribution only. If you want, you can also set up .npmignore
to hide most of the files since those probably won't be needed in Node environment.That will give a friendly build for Node users. This works with JSX, babel features etc. and should be enough for now.
@odf That looks good.
In one of our projects, however, we also use some webpack loaders to, for example:
require('styles.less');
I guess we'll have to hack those out for this approach. Better yet would be a way to do the same thing via webpack.
@martijnvermaat Yeah, the nice thing about this approach is that it's Webpack agnostic. I'm not sure if I understood that comment about hacking out styles.less
, though.
https://webpack.github.io/docs/stylesheets.html
This is a very convenient way to include styles, but of course a statement like require('styles.less')
has te be processed by webpack.
@martijnvermaat Yeah, that's the way I use it myself. I just require the CSS from somewhere with Webpack and let it deal with bundling etc. That's an issue separate to plexus-form, though.
Yes, this is getting a bit off-topic for plexus-form. Thanks for the heads-up!
@bebraw That looks like a good approach, the fact that it does not support fancy webpack tricks notwithstanding. I might give it a try on another project of mine, plexus-csp, which relies heavily on ES6 generators.
Now there is
"main": "lib/index.js",
Main field assume node env start point. There is no need to use packed version.This change will be help in debug time. Because we will be able to see separate files in debugger.
If you confirm, I can send PR.