Ive just published my first package (a react component) to npm but im having some trouble understanding the difference between what the lib directory is compared to the dist.
Currently I generate both lib and dist however my package "main" points to the dist unminified js file which has been built using webpack and output as UMD. The lib folder is built using babel taking the src and outputting to lib.
The dist folder contains both [unminified/minified].js files as well as [unminified/minified].css files.
My main confusion is with the lib folder since imports from there currently wouldn't work seeing as I just transform src -> lib meaning the scss references are still there and the scss files aren't transformed either.
I use CSS Modules (css-loader, styles-loader, postcss-loader etc) to generate my CSS files and this is where the confusion is since, wouldn't I also need to use webpack to generate my lib folder seeing as the scss files/import references need to be transformed to css?
Are you meant to have both lib and dist or is the UMD build in dist fulling the same purpose as that of having a lib folder?
If you are supposed to have both how would I achieve this, since I couldnt find any info regarding generating the lib folder when using CSS modules within your js files and still maintaing the same folder structure of that of src (while still generating dist)?
Usually the dist folder is for shipping a UMD that a user can use if they aren't using package management. The lib folder is what package.json main points to, and users that install your package using npm will consume that directly. The only use of the lib as opposed to src is to transform your source using babel and webpack to be more generally compatible, since most build processes don't run babel transforms on packages in node_modules.
As far as handling the style imports, it's probably a good idea to not import scss or css files in your source js that you export. This is because node can't import styles like that by default. If you have an example that demos your component, it makes sense to import the styles there. The common pattern is to publish minified and unminified css in the dist folder, and in your documentation tell the consumer to explicitly import the css file using whatever technique they prefer. I took this approach with redux bug reporter if you need an example. Hope that helps!
In general lib refers to libraries that are included in a package, dist on the other hand are distribution files for your project. As an example you could write a bunch of javascript and include jquery (which is a lib) and then when they're all bundled up you have a single dist file.
Ok think I found out how to do this. There is a babel plugin that allows you to use webpack loaders when running babel (babel-plugin-webpack-loaders). Thus my CSS mapping is inlined within the js file and the mapping hashes used are also the same as that used when building dist. Yay!
Related
Is it possible to build a TS source into a single file, which would also contain node_modules imported packages' source?
That would be very helpful in a serverless project. I have done this before on a non-TS project but was using webpack (for another reason).
It seems this was briefly possible before but was due a bug https://github.com/Microsoft/TypeScript/issues/13414 ?
You will need to use a bundler such as webpack to bundle your compiled code and all your node_modules dependencies. The TypeScript compiler (tsc) just transforms TypeScript code into JavaScript, and won't deal with bundling.
I start learning webpack , node , and react and I am bit confused about some basic staff.
Does webpack bundle whole react.js + my javascript files into one output file, so when deploying to production I don't need to install node packages used in project (assuming that they are added to webpack.config.js file) ?
If above is right:
On my server I just need to place index.html + output from
webpack ( bundle.js) ? ( In simple scenario) ?
package.json will be used only on development side ?
You only need index.html and the bundle.js (or any name you gave the file) for the app to work, provided that you are not using any local assets. You don't need to include node modules. Package.json should tell you what to include in your project so that you don't have to include node modules whenever you want to upload your project along with few other decalarations.
The way Webpack works is that you specify one or more entry points and one or more output files. Webpack then reads the entry point and also traverses through the import / require statements recursively. It then generates final bundle file(s) which includes all the traversed files.
Yes, Webpack outputs everything in the the bundle.js file(s). You can configure multiple output bundles. So, you just need HTML and output bundle to deploy the app.
The package.json specifies the packages upon which the app depends, apart from several other things. While traversing through the entry points, webpack will also include the packages specified in import / require. Function of package.json is to tell npm to install those packages.
I'm trying to get my head around this sass importer:
https://github.com/idcware/node-sass-jspm-importer
I'm not entirely certain I'm trying to use it correctly.
I'm trying to use the example of using it to import font-awesome.
The GitHub page provides the following example
gulp.task('build-sass', function() {
return gulp.src('src/sass/*.scss')
.pipe(sass({
errLogToConsole: true,
functions: sassJspm.resolve_function('/lib/'),
importer: sassJspm.importer
}))
.pipe(gulp.dest('dist/css'));
});
In this example I'm uncertain how much of a bearing this section has:
gulp.src('src/sass/*.scss')
How does this path make any sense when the SASS/SCSS files are to be imported from JSPM Packages which would have paths like:
jspm_packages/npm/font-aweesome#4.6.3/scss
The lib folder in this section
functions: sassJspm.resolve_function('/lib/'),
Should that be /jspm_packages/ since in the documentation it specifies
Where /lib/ is the path to your jspm_packages folder in your document
root.
In which case why did they not just specify jspm_packages?
I was thinking about this all wrong. One of the things I was missing was that with SASS/SCSS you can use import directives. As such rather than import many generated css files it makes more sense to have the SASS compiler/importer produce one single CSS File.
So I created a single SCSS file that was outside of my JSPM_Packages folder in src called SCSS.
In this SCSS file I could then place the following code
$fa-font-path: jspm_resolve("font-awesome/fonts/");
#import "jspm:font-awesome/scss/font-awesome";
The line in the gulp file:
gulp.src('src/scss/*.scss')
Can then find this single SCSS File and from there work out how to import all the SCSS Files for Font-Awesome through the JSPM_Package folder structure. A single main CSS file was then placed in the destination directory which contained the css from font-awesome.
Which in my case where I'm using ASP.NET Core looks like this:
.pipe(gulp.dest('./wwwroot/css'));
The functions line needed to be set to jspm_packages
functions: sassJspm.resolve_function('/jspm_packages/'),
I'm not sure why they have it as lib in their documentation - maybe this was an old JSPM configuration?
Is there a variable (or how to make such a variable) that refers to the package base directory (where package.json is)?
The use case:
I am using Babel to compile code from ES6 to ES5. ./src/ to ./dist/. Then I refer to the ./dist/ code in the main property of the package.json
The problem happens when ./src/ code uses files that are not JS, e.g. ./src/schemas/*.json. These files do not exist in ./dist/ folder. Therefore, when referring to non-JavaScript files from ./src/ I need to use a path that keeps a reference to ./src/ file.
I can already do this using ./../src/schemas/foo.json when requesting a file. Though, thats a fragile approach.
I know I can simply copy all the non-JavaScript files to ./dist/, but
duplication of content does not seem like an appropriate solution.
This is the appropriate solution.
Why ?
Your src folder should hold the source code of your project (not including dependencies & build routines)
Your dist folder is supposed to hold a standalone version of your app or website that you'll be able to distribute "as is" (you should be able to upload the content of dist via ssh/ftp or whatever to your remote server and it should be working)
Note: This thread is more about code organization than code itself (so anybody can have his opinion), but this is the kind of workflow yeoman and lots of build systems use.
I'm using coffeescript while writing a node js app and use cake watch to compile my js files real time.
That's great to be able to do that - but where should I stick those js files? Right now, I'm saving them right next to their respective coffeescript files, but that just feels awkward...
The convention I've gotten comfortable with is to put CoffeeScript files in a src directory and have "compiled" JavaScript output to a lib directory. Like so:
package.json
lib/mymodule.js
src/mymodule.coffee
If you publish the module to the npm registry, you can just include the resulting lib directory, which is conventionally where projects written in JavaScript keep there .js files. This keeps everything consistent.