Today I wanted to install https://github.com/eternicode/bootstrap-datepicker with jspm for my Aurelia project. So I did this
jspm install -y npm:bootstrap-datepicker
It didn't report any errors back, however the result was only a single .js file, when I checked in jspm_packages after the install. The folders and css files were missing.
I've asked in jspm gitter and reported it in github, it doesn't look however, like there a lot of activity or feedback in there.
For example I found this old pull ( https://github.com/jspm/registry/pull/204 ) which is still open, so I guess it is not likely that this will be fixed anytime soon.
So I'd be very interested in a an alternative workaround, if anyone would happen to know how to do such a thing. :)
The other files should in the bootstrap-datepicker#1.5.0 folder.
Check the path at jspm_packages/npm/bootstrap-datepicker#1.5.0 again.
Related
I'm new to Firebase. Recently, in order to fix certain errors, I tried many different ways until I feel that my local project folder is pretty much messed up, which could cause more other hidden problems. For example, I keep running npm init on many different folders, sometimes manually edited the package.json file, run npm install firebase#5.9.4 --save on several different folders and so on.
So I wonder, is there a way (or tool) that we can scan through our project folder and safely clean it up, e.g. remove redundant/unused dependencies, e.g. node_modules, add required dependencies, fix declarations/referencing errors, and so on without removing user-created assets like .js, .css, images etc.? I want to do that is because I believe this could potentially reduce many hidden problems and help to narrow down my troubleshooting tasks...
Alternatively, can I do the following:
Backup all my JS files.
Empty my Firebase's functions folder.
run firebase init again.
Restore my JS files.
Deploy and troubleshoot my Firebase functions again? Or any steps missing?
Sorry for a silly question. Any advice would be much appreciated, thank you!
If you think there is a problem with the contents of your node_modules folder:
Remove all node_modules folders completely. They don't contain any special information. It is just copies of modules downloaded from the internet.
Rebuild it completely with npm install from the correct location (your functions folder), which uses your package.json to determine what it should contain.
I have a project using VueJS, Webpack and some JS Plugins, like Jquery Datatable.
Everything goes well, i have a package.json where has all depedences. Here we a team with 10 developers. Not all of them work with this project, there are some developers that touch in this project every month. They already have all project, nothing changes with package.json dependences, but when i build the project, there are some strange errors in terminal, like not found some dependences(?) even all folders being there. Nothing changed with node_modules folder. If i delete it and run npm install, it works. The question is: "Why does the folder node_modules "lose" the references when it is a long time without moving the object?"
Thanks!
I'm trying to write an npm package that will be published and used as a framework in other projects. The problem is -- I can't figure out a solid workflow for working on it at the same time as working on projects that depend on it.
I know this seems super basic and that npm link solves the issue, but this is a bigger one than just being able to import one local package from another.
I have my framework package scaffolded out; let's call it gumby, It exports a function that does console.log('hello from gumby'). That's all that matters for right now.
Now I'm ready to create a project that will use gumby. Let's call this one client. I set that up too and npm link gumby so client can import from it, etc. OK cool, it's working as expected.
So now it's time to publish gumby. I run npm publish and it goes out to npm as version 0.0.1.
At this point, how do I get the published, npm-hosted version of gumby into the package.json for client? I mean, I could just delete the symlinked copy from my node_modules and then yarn add gumby, but what if I want to go back and work on it locally again? And then run it against the npm version again? And then work on it some more? And then...
You get the point, I imagine. There's no obvious way to switch between the npm copy of a package that you're working on, and the local one. There's the additional problem of how to do that without messing with your package.json too much, e.g. what if I accidentally commit to it version control with some weird file:// dependency path. Any suggestions would be much appreciated.
For local development, having the package symlinked is definitely the way to go, the idea of constantly publishing / re-installing the package sounds like a total pain.
The real issue sounds more like you’re concerned about committing a dev configuration to prod - you could address that problem with something as simple as a pre-commit hook on your VCS e.g. block if it detects any local file references in the package.json.
Before start using node package manager, i was just downloading packages into one folder and giving references from html files. Now i have started to use node package manager and i want to done thing right.
I have downloaded jquery via npm install jquery --save command. Jquery is downloaded with minified, unminified, source, readme etc files, so i got more than 30 files downloaded.
How should i use those files in production? I mean all i need is one minified jquery file in production. Should i delete rest before deploying? I feel like npm can make my life easier but i am missing the point.
How should i approach to this?
When you use npm, the dependency is gonna be used only on server-side. I recommend you search for bower, it has the same purpose npm has, but for the client-side.
And about minified and full versions it's ok do maintain both versions, as long as you configure that, on production, to load the minified versions of your libraries.
I would recommend against deleting the entire package even if you need 1 file as there probably won't be any harm having a couple extra files. npm will allow you automatically update packages in the future... something you may not be able to do if you manually include a single file.
I've encountered something in node.js that'd I'd like to submit a patch for. I've also located a Github issue in which somebody also complained about the same annoyance. The issue has been tagged saying that patches are welcome. So, I'd like to try to supply a patch.
But, what's the best way to do this? I've forked the main node repository, and I've located the spots in the C++ code that an adjustment could be made. Before I make these changes though, I am trying to figure out how to test these changes of mine. I've got the official node package installed globally. I'm on Windows. How can I test this modified version of node?
You can install node-gyp to build the addon manually (npm install node-gyp -g). Then just change to the addon's root directory and simply do node-gyp rebuild after you make changes.
After further investigation, the vcbuild.bat produces project files that can simply be opened up with Visual Studio. So, code editing and debugging can all easily be done within VS. Awesome!