How can I precompile multiple vue files in a single library and keep them easily importable? - vue.js

I have a program with multiple .vue files in src/components. These use typescript and sass. The program uses webpack for compilation and bundling. I would like to add all these components to a single npm package to be used as a library with the following restrictions:
It should be compiled down to javascript and css so whoever imports my library doesn't need my compile dependencies and webpack configuration
The components depend on typescript files. These should also be compiled, but not bundled. They are valid entry points for the library.
The import for the users of the library should be as painless as possible. It would be optimal if the generated js and css could be loaded in a single import, just like importing a .vue file
Is this possible to do? And if so, how? If not, how could I best approximate this or what are my alternatives?
I have tried to use vue-cli-service build --target lib but it seems that can only handle one component, bundles the ts files, and I'm not sure if it behaves like I expect when you import a file.

Related

Is there a way to compile various SCSS and SASS files together into one SCSS bundle file?

I'm currently building an npm component library and i'm using a rollup bundling process to compile the library for distribution. The css for the project is written using SCSS, but it also depends on Bulma, which is a css framework written in SASS.
What I would like is to be able to bundle the bulma source code along with my custom scss all into one scss file that I can then use in other projects. That way I can still benefit from the features offered by scss in those projects, such as variables and mixins for example.
I would like this to be automated during the build process so that I don't have to worry about it while developing new components. I've looked at many npm packages for bundling scss files but none of them support SASS and SCSS together. I've also tried converting my project entirely to sass but there doesn't seem to be any good support for sass bundling in general.
So for example, I may have a main.scss file that looks something like this:
#import "~bulma/bulma.sass";
#import "./utils/variables.scss";
It imports both sass and scss files together. This is something that is supported by the sass compiler, and I can compile this to a bundled css file without any issues. But there does not seem to be any support for bundling into one scss file.
The two main NPM packages that i've been attempting to use are:
scss-bundle & bundle-scss
scss-bundle is great, but it doesn't seem to have SASS support, so that's a no-go with Bulma.
As for bundle-scss I converted my project to use SASS and configured the package accordingly, here's the config is used:
{
"dest": "dist/bundle.sass",
"mask": ["src/styles/**/*.sass", "node_modules/bulma/**/*.sass"]
}
From what I can tell, this should go through all of the files in all of the subdirectories of both my styles folder and the Bulma dependency folder and compile them together into one bundle.sass file. And although I would prefer the configuration options from scss-bundle, this is essentially what I am looking for.
However it doesn't work. The package can't seem to resolve the #import statements within the SASS files. Regardless of the syntax I use. And even if it was based on syntax, I can't change Bulma's syntax. Could it be that I'm using the wrong globbing pattern in the mask option? Or does this package just not work?
So my question is, and TLDR:
Can I bundle SASS and SCSS together into one file using some NPM package?
If not, is there a simple and automated way for me to transpile SASS to SCSS and then bundle them together?
If neither of those are possible, is there a working npm SASS bundler that someone can direct me towards? Because bundle-scss does not seem to work.
Also, I am aware that I could just import Bulma separately into the project that needs it, but i'd really prefer to have it all come down together in one package.
Thanks! I hope I explained everything clearly!

Why would one need gulp-concat, even though browserify is already being used?

I was of the understanding that Browserify could be used to bundle various JavaScript files into one. However, after looking at some examples on the internet, I found that some people use Browserify and yet they also include gulp-concat.
For example, the angularjs-gulp-example project uses both.
Why? I thought Browserify could do the concatenation as well.
Browserify is a bundler that creates JavaScript bundles from CommonJS modules. Typically, the bundle will contain all of a project's source files and all of the CommonJS/UMD dependencies. (Also, like Node, Browserify can require JSON files, so they could be in the bundle, too.)
If a project has dependencies that are not included using require and are instead indended to be used in <script> elements - the build process might opt to use a tool like gulp-concat to concatenate them to the front of the bundle.
That's likely why gulp-concat is used in the project you referenced in your question. It concatenates an Angular template cache that's generated from .html files - something Browserify doesn't deal with (unless a transform has been configured).

Should I include whole bower_components and node_modules folder in my web project?

When I download a package in bower or npm, many irrelevant/not-useful files also
get included especially in npm packages. I generally only include .css or .js files of that package for e.g. in bootstrap e.t.c. But for package like polymer or Anjular.js or Electron we need multiple other file too. So when I deploy my project should I include the complete folder or just copy the required files separately or is there any other approach ?
When you deploy to your production server, a good approach would be to only include the files you are actually using. You should also create an optimized file to serve to the client.
To achieve that, you normally have a deploy script that generates one or more minified .css or .js files (for example, vendor.js for libraries and bundle.js for your code).
This script can be build with tools like grunt, gulp or you can use a module bundler like Webpack or Jspm.
You can create your own Grunt or Gulp script like the ones in this website.
When using a module bundler and modern javascript to organize your code, you'll build, for example, an entry javascript file (bundle.js) that will look like
import {MyLibrary} from 'my-library';
import {AnOtherLibrary} from 'an-other-library';
console.log(MyLibrary.saySomething());
In this case, Webpack handles the node_modules imports and the creation / minification / concatenation of the production version of .js files.
As you said, there are multiple files to be included (js, css or even fonts) so configuring your scripts may take some time. Try finding a Yeoman generator that uses your frameworks, and use the deploy scripts others already created for this purpose. This one uses AngularJS, Bower and Grunt. This one uses Webpack and ReactJS.

How to write a multi-file NPM package with Brunch

I have a multi-file project, with ES6 style exports and imports.
I'm using Brunch to concatenate these files into 1 main.js file that will serve as the main for an NPM package.
To specify the API of my package, I need to have exports in main.js. But when Brunch concatenates my js files, I am worried that (1) exports that are meant for internal imports and (2) exports meant for my API will both look the same.
Looking at the generated main.js file it seems like the exports I write in my source code get wrapped into modules, but none of these are top-level exports like the ones needed for NPM packages.
How can I let NPM distinguish between these two types of exports? Specifically, how can I have exports in the main.js file generated by Brunch concatenation?
Brunch is not designed for writing libraries, but rather for building apps.
I don't need to concatenate files at all to publish them to NPM, so instead I have used Babel with React and ES6 presets to transform my ES6 .jsx files to ES5 .js files.
I then make one file (eg. main.js) where I export my library and set that as the main in package.json.
I can then use Brunch to create an app with the React skeleton (brunch new -s brunch/with-react), npm install <my-package>, and import my library within my app.

Why is browserify pulling in a lib 2 times? - Browserify

I have an Angular app where I use browserify to manage my dependencies. I am also using momentjs to do all my time manipulation. I have several modules that I am using browserify to build, but it is pulling in momentjs more than once, even when I use the external command. Here is my code. First I have a base module that has all of my shared libs:
require('angular');
require('angular-route');
require('moment');
Here is the code I use to browserify in my gulpfile.js:
browserify().require('./js/donor/donor-libs.js')
.bundle()
.pipe(source('donor-libs.js'))
.pipe(gulp.dest('./build'));
This builds out fine and has the libs that I would expect including momentjs.
Now I go to build a module that is dependent on this module. momentjs is used in this module. Here is the code that I use to build the module:
browserify().require('./js/donor/history-module.js')
.external('./js/donor/donor-libs.js')
.bundle()
.pipe(source(filename))
.pipe(gulp.dest('./build'));
Now when I look in my build directory, I have momentjs in both the donor-libs.js and my history-module.js. Why doesn't it recognize that I have already required in momentjs in my donor-libs.js? What do I need to do to only require in 3rd party libs one time? What don't I understand about the external command?
The reason libs are being pulled in multiple times is that the external command is being used improperly. external is expecting a path or an array of paths that will externalized. external will not look through a js file and find the required files and then not pull them in other modules. The code should of looked something like this
.external('angular', 'angular-route', 'moment')
or the path to the required lib. This would of externalized these files and fixed the problem of a lib being pulled in multiple times.