I am using npm, yarn build as manager tool. Using these tech, create two project , CommonLib and SampleProject. so first I build CommonLib project, release its library and publish it to AWS codeartifact then ref that published artifact to SampleProject.
This flow looks fine and works well as well. But this whole process force us to publish our changes to artifact which block other.
So not think to do change locally in IDE (here is mscode), release it locally and then ref it to SampleProject.
I used npm install ../CommonLib command to install the package and IDE start point to locally project. But it doesn't compile the project.
Can anyone help me on this, what could be wrong here.
Related
I'm developing both an application and a package which it will depend on. I'd like to use git submodules to include the package in my dev environment and build using a published package from npm when I compile for production. What is the easiest way to achieve something like this?
Working on a larger typescript project we decided to move the code to a monorepo with yarn workspaces.
We use webpack to build and bundle and everything works well (especially the linking between local modules/packages).
Since yarn workspaces will store most of the node_modules in the mono repo's root folder, the IDE (IntelliJ as well as VSCode) have problems resolving the imports to any node_modules when coding inside a "inner" project (so called "package" of a monorepo).
The strange thing is that imports are not known but on the other hand most of the time you can navigate to the correct source / definition within the IDEs for the same import if you write it down manually.
We have tried to tell IntelliJ to look into another folder for node_modules, but still not satisfying.
Please share your experience with yarn workspaces / monorepo (e.g. lerna) and how you develop the code living in these monorepos.
Which IDE do you use?
Did you add any special configurations to the IDE and/or package.json, tsconfig.json?
https://github.com/Izhaki/mono.ts
It uses yarn workspaces and marry well with VSCode. I hope the README is clear enough.
Basically, use two (parallel) typescript configuration trees:
Pre-build - uses aliases (for VSCode, tests, webpack, etc).
Build - uses typescript 3 project references for publishing essentially.
IDEA doesn't provide any support for Yarn workspaces; if you miss it, please follow WEB-29250 and linked tickets for updates.
You can try adding path mappings to your tsconfig.json - see https://intellij-support.jetbrains.com/hc/en-us/community/posts/207656825/comments/115000529564
Upodate as of 2018.1.1 IntelliJ now supports yarn workspaces so if you use this there should not be a problem.
https://blog.jetbrains.com/webstorm/2018/04/webstorm-2018-1-1/
Please share your experience with yarn workspaces / monorepo (e.g. lerna) and how you develop the code living in these monorepos.
Which IDE do you use?
Since you are asking. I basically ran into the same issues as you did. One solution I was looking into was disable hoisting node modules as described here. Unfortunately it seems it is not yet in the stable release.
What I ended up was ditiching workspaces for now until they fix either the IDE or release the nohoist option. Instead I am using lerna for now. It is less convenient but it does not hoist so that both the build tools and the IDE are satisfied.
Oh, I am also using IntelliJ (ultimate)
The manual states that
You can also install the package globally on your machine and use the
wdio directly from the command line. However it is recommended to
install it per project.
Why is that? What downfall should I worry if installing globally?
If you only wish to use webdriver only in your shell regardless of any project then you can install it globally. However, if you wish to use it in a project, such that it is required to run project tests then install it locally (in this case it should be devDependency). The reasons are:
1) When multiple people working on a project, it is ensured that all of them have the same versions of the required packages.
2) Portability. The project dependencies should be completely defined in package.json so that after running npm install the project is ready to use in every environment.
For people new to NPM and Node, I'd recommend a global install to keep it simple. There are reasons to install it locally though, mostly to do with version compatibility and ease of project sharing: https://www.joezimjs.com/javascript/no-more-global-npm-packages/
How can I support these NPM/ember addon scenarios?
developers build ember addon A and use build ember application B which uses their A local package
developers only builds B installing A from our nexus NPM integration repository
build system builds ember addon A installing into our nexus NPM release repository
Maven
developer desktop builds install packages to a local repo to be used later in the build.
build system builds deploy packages to our internal shared repo to be used by developers so they don't need to build all
NPM
build system builds can use npm publish --registry http://ourrepo/nexus/.... to publish into a private registry
develop desktop builds do????
We could use DependsOnMe with relative paths but that requires us to setup some kind of rule where builds work one way locally and another on the build machine.
While possible, I hope there's a more elegant solution to making this happen.
Can I have developers generate packages that go into the local npm cache for later use and if so can you point me to that documentation?
Related
locally build npm package in project
nexus npm deploy doc
Because we use maven front end plugin to manage npm and ember we can encapsulate an additional npm module (in this case an ember addon) as a maven artifact and make use of maven dependency management for our various scenarios
Ember Add On module
add 'npm pack' to generate local package in npm repository (in our case root/target/tmp/.npm//)
add assembly to generate tar.gz containing tar file (a little silly) and attach it to module as an artifact (type: tar.gz, classifer: ember-addon)
Client module
add maven-dependency-plugin unpack which unpacks addon module's tar.gz classifier: ember-addon to target/ember-addons prior to npm execution for this module
modify package.json to use local dependency "our-addon" : "file:../../target/ember-addons///package.tgz"
If a user builds ember and client, then addon module build placing the artifact in local maven repository. Client module unpacks from local repository and pulls into node_modules via npm ember build process.
If a user only builds client, then client module fetches addon artifact from our nexus repository prior to the unpack and use phases.
My team uses an internal team maven repo that is shared from a development server using Apache. We also run the Continuum CI server on the same machine. Maven builds in Continuum are run with the "install" goal, which copies the final artifact directly into the shared directory.
The question is, what is the difference between adding files to the shared repo using mvn install and using the deploy goal (mvn-deploy plugin)?
It seems to me that using mvn deploy creates additional configuration hassles, but I have read somewhere that installing files into a shared repo is a bad idea for some reason related to the internal workings of maven.
update: I get the functional differences between deploy and install; I am actually more interested in the low level details in terms of what files are created in the maven repo.
Ken, good question. I should be more explicit in the The Definitive Guide about the difference. "install" and "deploy" serve two different purposes in a build. "install" refers to the process of installing an artifact in your local repository. "deploy" refers to the process of deploying an artifact to a remote repository.
Example:
When I run a large multi-module project on a my machine, I'm going to usually run "mvn install". This is going to install all of the generated binary software artifacts (usually JARs) in my local repository. Then when I build individual modules in the build, Maven is going to retrieve the dependencies from the local repository.
When it comes time to deploy snapshots or releases, I'm going to run "mvn deploy". Running this is going to attempt to deploy the files to a remote repository or server. Usually I'm going to be deploying to a repository manager such as Nexus
It is true that running "deploy" is going to require some extra configuration, you are going to have to supply a distributionManagement section in your POM.
From the Maven docs, sounds like it's just a difference in which repository you install the package into:
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
Maybe there is some confusion in that "install" to the CI server installs it to it's local repository, which then you as a user are sharing?
"matt b" has it right, but to be specific, the "install" goal copies your built target to the local repository on your file system; useful for small changes across projects not currently meant for the full group.
The "deploy" goal uploads it to your shared repository for when your work is finished, and then can be shared by other people who require it for their project.
In your case, it seems that "install" is used to make the management of the deployment easier since CI's local repo is the shared repo. If CI was on another box, it would have to use the "deploy" goal.