I'm trying to build a library (mostly some .vue components) to reuse in different projects (no public npm) with vue-cli-service. Apparently everything its already setup, and I can confirm that the build is fine (js, and css). However, I'm unable to use it in a separate project as an external module because it uses the spread operator (and probably more ES20XX features no yet parsed).
Module parse failed: Unexpected token (2683:8)
You may need an appropriate loader to handle this file type.
| params() {
| const queryParams = {
| ...this.filters,
| ...this.sorting,
| ...this.config.params,
This is the standard command I'm using to build the library
vue-cli-service build --target lib --name [mylibname] ./src/components/index.js
By default the bundle should be already polyfilled but it seems to me that it's not the case.
I've read that I might change the webpack configuration on the project I'm using into, but I'm against parsing the whole node_module folder and also I would love to just have the simplest workflow possible (like import a module and its css).
So my question is, how to polyfill my bundle to be perfectly usable in no matter what Vue project without any hassle ?
Ok, it seems that reinitializing the project with vue-cli without typescript and with separated configuration files instead of into package.json was a good idea, as now is transpiled as needed.
var queryParams = _objectSpread({}, this.filters, {}, this.sorting, {}, this.config.params);
Unfortunately the hidden configuration of vue-cli webpack can't help to see what has changed.
Related
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.
I am trying to create a plugin that utilizes components from another Vuejs plugin (Vuetify). Basically, I have some common components I want to share across multiple applications with our company.
I thought it would just be a matter of:
Create a github repo for the shared components
Author the plugin
Reference the repo in consuming apps via npm install
Here is the gist of the plugin:
// src/index.js <-- package.json/main is set to "src"
import MyComponent from "./MyComponent.vue";
import * as api from "./api";
export default function install(Vue) {
Vue.component("myComponent", MyComponent );
Vue.prototype.$myApi = api;
}
At the moment, the behavior I'm seeing is:
GOOD
plugin install function is being executed
functions from api attached to Vue.prototype are available in app components
my-component is available in the app and renders markup
BAD
$myApi and Vuetify components are not available in an application instance of of my-component
If I copy the same files into the app and change my import, all works as expected. So, I now wonder if I'm missing something regarding sharing code via external modules.
I've tried these alternatives with the same issue:
use npm link to link the plugin module to the app
manually, use mklink (Windows sym link) to link plugin module to node_modules in the app folder
use a long relative path reference to the plugin module: import MyPlugin from "../../../my-plugin"
I've put this issue off for a while, but for anyone wondering, the issue is with using Single File Components and webpack not compiling those in external modules.
The 2 options I have are:
Don't use Single File Components. I.e.: Just use .js instead of .vue. I've seen some libs like Vuetify.js take this approach
Compile the .vue files in the library module and include them in the source such as ./dist folder.
I'm putting together a streamlined development process with react and react-native that:
encourages packages,
uses babel to transform es6 to js (it compiles before publishing/installing),
has a playground that let's you play with both native and web components.
The web part of it is perfectly fine. It's the native one that's causing issues and it has to do with react-native's packager.
The bottom line is: if the package is either linked through npm link or required directly from the playground as in require('../../') react-native's dependency resolver will go forever trying to identify dependencies inside my package's node_modules, most times it never finishes doing it.
The temporary solution I've found is to install the package in playground but this involves re-installing it every time I do an update, which isn't great because you can't see your changes right away (even if it would be automated, it would take time).
I believe that a better solution would be to ask the dependency resolver to ignore those specific modules I don't need (those in devDependencies mainly!). I tried mangling react-native/packager/blacklist.js by adding paths to that list and even putting checks against the dependency resolver but none of that would work.
Can someone with more experience with the packager give me a hint as to how I'd go about making the dependency resolver pass? Alternatively, it would be great if the packager could be separated and the transform process left to choice but I don't know if that would be doable either.
I found out the following solution, based on the comment in default.config.js:
* If you need to override any of this functions do so by defining the file
* `rn-cli.config.js` on the root of your project with the functions you need
* to tweak.
Create a rn-cli.config.js in the root of your project with the following contents:
var blacklist = require('react-native/packager/blacklist');
var config = {
getBlacklistRE(platform) {
return blacklist([
/node_modules\/my-package\/excluded-dir\/.*/
]);
}
};
module.exports = config;
The second argument to the blacklist function is an additional list of blacklisted paths, which can be regular expressions. See react-native/packager/blacklist.js for more examples.
According to http://www.slant.co/topics/1089/viewpoints/1/~what-are-the-best-client-side-javascript-module-loaders~browserify#9 one of the downside of using Browserify is that:
Not all javascript libraries have an npm version
While it's not too hard to create npm package for an existing library, it means maintaining it when the library updates. While most libraries are now on npm, many client side specific libraries are not.
I don't have any experience with npm aside from knowing how to install an existing module. In light of that, what is the easiest/best way to browserify with client-side non-npm libraries?
Is there a way for me to declare a local Javascript file as a dependency, instead of looking it up through npm?
You can use local modules without problems by two ways:
1.Use a relative path to a module in require:
var myModule = require('../js/my-module');
2.Use a module name, but before, you should to add it to browser property in package.json:
package.json:
...
browser: {
my-module: './js/my-module.js'
}
app.js:
var myModule = require('my-module');
Some packages are packages with bower, these can be used with browserify by using the debowerify plugin.
For non-versioned things you can copy them to a lib directory in your project or add them as a git submodule and then configure browserify so that it can find things there too.
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.