msurdi / frontend-dependencies Goto Github PK
View Code? Open in Web Editor NEWCopies node packages to a directory where your frontend tools will be able to find them
Copies node packages to a directory where your frontend tools will be able to find them
This is part of my package.json.
"frontendDependencies": {
"target": "assets",
"packages": {
"jquery": {
"version": "^3.0.0",
"src": "{dist/jquery.min.js,dist/jquery.min.map}",
"target": "assets/js/jquery"
}
}
}
From semver calculator, it should working with jQuery 3.0.0 to 3.4.1 (current latest version). But I just got 3.0.0 always.
I have to change from ^3.0.0
to >=3.0.0
to make it working.
In version 1.1.3 has been added the modulePathPrefix variable, which cause my build to break:
[frontend-dependencies]: build the "npm install" command: npm i --no-save --prefix node_modules/frontend-dependencies bootstrap-fileinput
That causes the creation of a wrong path:
Module not found or not a directory: /home/user/myproject/node_modules/frontend-dependencies/node_modules/bootstrap-fileinput
With version 1.1.2 I had a simple
[frontend-dependencies]: build the "npm install" command: npm i --no-save bootstrap-fileinput
[frontend-dependencies]: installing ...
[frontend-dependencies]: copy all specified files
[frontend-dependencies]: copy /home/user/myproject/node_modules/bootstrap-fileinput/js/fileinput.min.js to /home/user/myproject/src/main/resources/META-INF/resources/js/plugins
Should be possible to have that variable as a configurable variable inside package.json?
Thank you
Could look like this in the options:
"jquery": {
"version": "3.1.0",
"files": [{
"src": "dist/*"
"target": "test"
}]
},
Usecase: Now you are able to store common backend and frontend code into any folder you like from one npm module.
The issue is currently for documentation as I might implement it.
It wouldn't take much work to extend this so it can work as a standalone CLI package.
It would need a CLI entry-point like https://github.com/evanplaice/node-ftpsync/blob/master/bin/ftpsync. Then set the bin
property to point at the entry point.
Once that's done it should be able to run the script directly from the CLI by.
Installing locally then:
npm run [package-name]
Installing globally then in the CLI:
[package-name]
Launching via NPX without installing:
npx [package-name]
This could also be extended to run an alternate config.json by specifying a --config
argument from the cli.
Hello,
thank you for this package! I need stuff in this direction.
Currently I dislike, that there is redundancy in the package.json - meaning you have to specify your packages once in the dependencys and then also in the frontendDependencys. What do you think of the following syntax:
from https://github.com/msurdi/frontend-dependencies/blob/master/fixtures/package.json
{
// usual package.json stuff here ...
"devDependencies": {
"jquery": "3.1.0",
"normalize.css": "4.2.0",
"turbolinks": "5.0.0",
"shelljs": "0.7.4"
},
"frontendDependencies": {
"target": "static/build",
"packages": [
"jquery/dist/*",
"normalize.css",
"turbolinks/{src,LICENSE}"
]
}
}
{
// usual package.json stuff here ...
"devDependencies": {
"shelljs": "0.7.4"
},
"frontendDependencies": {
"target": "static/build",
"packages": {
"jquery": {
"version": "3.1.0",
"src": "jquery/dist/*"
},
"normalize.css": {
"version": "4.2.0",
"src": "normalize.css"
},
"turbolinks": {
"version": "5.0.0",
"src": "turbolinks/{src,LICENSE}"
// any other options can be added here easily
}
},
}
}
"packages": [
"jquery",
"normalize.css",
{"src":"jquery/dist"},
{"src":"normalize", "target":"vendor"},
{"src":"jquery/dist/core.js", "target":"js/whatever.js", "exact":true}
]
With the new syntax, the npm install
would not fetch the dependencies for the frontend - the script would have to do this on postinstall
. But this should not be a problem, as the script is already running postinstall
.
What do you think?
I was not very happy with bower
in the past. Just one more source of trouble. Also Webpack etc. are not bad, but do not what I want.
Currently I'm managing npm frontend dependencies with multiple grunt tasks: I have to look into package.json, Gruntfile.js in several places and in the index.html - seems ugly to me. One place in package.json and one in index.html seems enough for me.
I had a look at pancake
. https://github.com/govau/pancake
I consider it overkill. I think my suggested syntax could be extended also with packaging (sass, minifier), but I see no real need for it, as most packages come with a ready to use (compiled and minified, etc.) version of js and css. With http2, the sending of small files is encouraged. Another advantage is, that the browser can cache common libs easy.
Keep it simple stupid. I consider your lib currently as the best way and hope I can add a little value :-)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.