I have a project that exports a package to be used by other projects (some infra code).
I've published it in a local repo, and then installed it on my main project.
I need to keep working on that infra project, and to have it updated in the larger project. I have no problem running scripts to do that - but I don't want to increase its package version and to keep publishing it on any change.
I know about npm link and I've been trying to use it, but it seems that some caching in WebStorm causes it to not update in the main project. I actually need sometimes to invalidate caches and restart the IDE after changes to the infra package - and that's a large time consumer.
Is there a way to tell WebStom "for this npm package I want you to use this path instead of the actual npm package"? Or to use the "Attach project" feature to do that when both are open?
Edit: After working like that a bit, I've discovered that the need to invalidate cache is related only to TS related changes - meaning when I add classes or change signatures. I can write the correct code and it works - but TS shows errors and no autocomplete until I invalidate the caches. And restarting TS service doesn't help.
Related
Is there a way for Hot Reloading to occur on a local npm dependency of a local Vuetify application using yarn serve (which is probably using webpack / vuetify-loader)?
BUSINESS CASE
We have some common Vuetify components that I'd like to expose with a "common-components" Vue Plugin and allow all of our Vuetify applications to pull those common components. I'm able to do so by packaging the plugin and creating the dependency and pushing to a private npm repo or a commit/push to a private git repo. The problem lies with the development cycle and development experience.
A typical development change to the Plugin within the local development environment requires:
(common-components) yarn build (to create the dist/common-components.umd.js)
(common-components) (deploy to a private npm rep or a commit/push to a git repo)
(application A) yarn upgrade common-components to pull the latest
(application A) yarn serve
There has to be a better development cycle than this, right? Or is my real problem that we need to decouple the plugin from our applications better?
THE SOLUTION I WAS HOPING FOR, BUT FAILED
yarn-link or npm-link
I was able to get this to work, but a NPM dependency still resolves to the folder's package.json which has a "main": "dist/common-components.umd.js". This requires me to do a yarn build which removes the file and rebuilds it. When the file is removed, "application A" that is currently running with yarn serve breaks and is unrecoverable. I must shut down the server and do a yarn serve again.
I'm hoping there is a solution out there that tackles this scenario!
I've done that kind of setup a while ago thanks to yalc.
It was essentially:
work on your own package, setup it (with yalc link if I remember properly)
when an update was done on the package, we had it to automatically yalc publish --push --changed like with a linter
you can use a pre-push git hook to babelify your package
on the host main app, we had a nodemon running to check if yalc published any changes, and if it was the case, simply reload the app
on main app still, we used a git hook on pull to have it fetching the latest changes on the yalc.lock store (with yalc update)
I did it a while ago so I don't remember it super well but it was working pretty well as far as I remember, just need to run 2 servers (one on the package to publish and one on your main app to fetch the changes) on top of your other services. Still works better than it's yarn or npm links.
I have made a few applications (using webpack, babel, react, d3, npm etc.) that uses very similar charting code. I am in the process of splitting out that charting code into an npm package which multiple apps can then import.
To test this out, I've embedded a demo app inside my chart libraries project directory and install the library at its file path. Now, presumably i'll be able to install this in depending apps A, B and C and so on, and I can change my chart libary and all apps will reflect these changes.
The first thing I noticed is that I now have to cd into my chart library and run npm run build (which runs webpack) any time I change something, and then cd into the depending app I'm working on and run npm i. This can perhaps be improved by using npm link but there are issues there as well (such as versioning and deploying to my server). So my first question is about what a decent rapid development approach looks like now that my charting code is in a separate npm project.
The other problem I've noticed is that I've lost two valuable features with respect to my chart library code. Code completion in VSCode and debugging in chrome dev tools. I'm not sure why VSCode code completion has stopped working. And for debugging, how would i be able to debug both my depending app and the library its depending on at the same time in chrome?
I would use npm link. It's immensely helpful when working on a library and its integration side by side.
Check the Chrome settings to make sure it's not instructed to skip libraries in Settings -> Framework Blackboxing, see e.g., http://blog.edenhauser.com/tell-chrome-debugger-to-ignore-libraries/.
I want to understand what the react-native upgrade command is doing, it sometimes changes the gradle files:
android/app/build.gradle
android/settings.gradle
Why does it asks if I want to Y/N to update does files? If I keep answering No is this gonna have bad impact on the application?
The upgrade command is intended to run after updating RN version in existing projects (and after running npm install so the new version is in your node_modules).
Essentially, the command copies all files from the app template which is used to initialize a new RN app. The template is what you get when you run the react-native init command. This is also the reason why it needs to run after the new RN version is installed, because the templates app comes with the react-native dependency itself.
The reason that it asks you if you want to replace each modified file is that it doesn't know why the content has changed. It's possible that you made changes to a file yourself after you initialized your RN app.
If you haven't made any changes - it is safe to replace the existing files; it would be as if you got the file after initializing a new RN app. If you did modify a file - I think that you'd still like to see what changes were made in the new version (they can sometimes be required), in this case you can approve the replace (assuming that you're using source control...) so you can review the changes and in the worst case you can reset them if they're not necessary.
Alternatively, you can use React Native Git Upgrade which can help you resolve conflicts more easily.
I read about npm and bower, differences, usage, how it works, purpose as well. All explanation says that to work in NodeJs. But when I searched for AngularJS2, the tutorial says use npm. I have some basic questions based upon the understanding that npm basically for dependency management or packages to be installed.
How my Java/Eclipse workspace knows that npm installed the particular JS library/file, what path should be given in the html/web page for including those files/libraries?
If I move the web application to production, how will the server gets those dependent libraries? Even if server gets it, it might be installed in different folder. Basically how it can be managed with a web applications in different environments for just AngularJS app?
Can anyone please help me to have better understanding?
Finally found the answer. NPM is node package manager which helps basically to download the dependencies (almost like maven, gradle in java).
npm software needs to be installed in developer's machine.
Add the required dependencies in the package.json in the root folder of AngularJS application.
Open the DOS command line and navigate to project root folder(workspace/project in eclipse), then type npm install which will download all the dependencies mentioned in the package.json to a folder called npm_modules inside project folder.
The other and important advantage is npm can be used to install browser agent as well. So npm start command will open the browser and will load the application automatically in browser. Developer does not need to be aware about NodeJs. One more benefit of using this approach is the browser will get refreshed automatically when any update in the JS file gets saved.
I am looking at nuget for improving automatic handling of dependencies (both internal and third party) during development.
A long as you develop through the CI Build Server, all is good:
get latest source for A and B, where B depends on A
fix bug in A
build A
check into source control
CI Build Server initiated
new nuget package is created and placed in corporate repository
build B (which will get the updated A package)
run B to verify that the bug in A was fixed
n. repeat n times
However, I'm wondering if it is possible to work locally as a single developer, without having to wait for the CI Build Server to produce a new package?
Nuget has a feature Package Restore, which will download all dependencies automatically on build. You can also list the repository order that the Package Restore should look for packages.
If the workflow could become:
get latest source for A and B, where B depends on A
fix bug in A
build A
(building creates a local nuget package)
run B to test the (resolved) bug in A (should now use our local nuget package, not local repository)
...repeat n times
check into source control
CI Build Server initiated
new nuget package created in corporate repository
Is this possible using Visual Studio, MSBuild, a CI Build Server and nuget? I'm especially interested in the making of local packages while developing locally.
Note that I have native projects, although except the generation of nuget package post-build, this would be a workflow that I hope should work for both C# and C++ projects.
The solution I have now, though far from ideal, is what I could figure out works best. Oh! and it is a work in progress so it WILL change in the coming weeks/months as I figure out how to get around the kinks.
I mostly have to deal with managed DLL right now but I do have some native code and worst, multi-platform native code to deal with eventually.
Create a local repository, basically just a folder and configure it in your list of nuget feeds.
Then I created a task (MSBuild) that will package the project and output it in the local repository's root folder. Make sure the version of your package is always increasing. Presently I do this manually by editing the assembly version.
Once built, update your other projects that reference it, I usually do this though the package manager console (update-package).
Each projects that was updated, bump up their version rinse lathe and repeat until you get to your top-most project (the actual program).
Once everything is nice and good and you are ready to commit then the build system should do it's own packaging and send it to your official repository.
The Good
No clogging of the repository and build system with intermediary development versions, that garbage remains (as it should) local.
Local repos are super easy to set-up, can even be done without changes to VS though the global nuget config.
This is friendly to both paradigms of package recover or checking-in packages with the project. That said I would recommend not checking in the packages you built locally but rather one that was committed to your local repository ideally through the build system. What's built local should remain local.
The Bad
Still much more complicated than just adding projects to a solution.
The deeper (or wider) your dependency tree the bigger the pain.
The Ugly
Makes some native nuget behaviors quite quirky and annoying :
Update operation takes forever if your VS is connected to a version system (perforce for me). I hear they "solved" the problem, would hate to see how it was before if it was worst that it is now !
Having nuget change non-code reference back to never copy is a major pain.
If Only
Configure the desired state of a content dependency (copy always, never or newer) directly from the nuspec and be done with it ! (oh and same story with ClickOnce content status include, exclude etc)
Make the update operation quick, 2 minutes for a dozen project is just insane, especially if the ultimate goal is to manage 500+.
Perhaps a hybrid mode where locally we work with projects inclusion but the build system would work with nuget dependency (and build them if necessary)
If you are to parse the project do follow MSBuild parsing rules and honor the conditional statements.
There are still issues I have yet to figure out like how to manage multiple branches of the code in the repository. How to handle version conflict further up the food chain. In a large project (ultimately we have to bring 500+ separate projects together in a single application executable, conflicts are expected).
I would love to bring all the goodness of sane dependency management à la Maven but thus far I did not find nuget to be mature enough to even think of proposing it to the dev team.
Certainly. In our solutions, NuGet parks the libraries in the "packages" directory of the solution's hierarchy which is ultimately kept in TFS. This allows for complete solution check-outs that includes the required libraries. If it's your intention to update the libraries normally provided by NuGet, you'll need to update the dependent projects' references to point to the project containing the updated code normally provided by the NuGet process.
Prior to checking-in your regular solution work (not the NuGet related libs,) make sure the solution's NuGet libs are up to date, and the references in the solution point back to the NuGet installed libs. Of course, you'll check-in and fetch the NuGet related libs beforehand.