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/
Related
So npm allows a preinstall script to run before installing a module. For example, puppeteer uses this step to install headless chrome. Is there any way to do something like this with deno?
Unlike Node.js, Deno has no package manager. Instead of installing packages, all modules and dependencies are simply cached as static files for use at runtime — there is no configurable hook for an "installation step". Any code which requires an external dependency (such as a coordinating process in the case of Puppeteer) must ensure that such a dependency exists at runtime using program code. See Creating a Subprocess in the manual.
See also section 3.1 of the manual Basics > Modules for information about the module system.
For an example of a Puppeteer implementation in Deno, see https://deno.land/x/puppeteer (source GitHub repo).
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.
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)
I am trying to use squeakSSL with WebClient, the squeakSSL page says:
To install SqueakSSL you need to download and install the binary version of the plugin and then install SqueakSSL via:
(Installer ss)
project: 'SqueakSSL';
install: 'SqueakSSL-Core';
install: 'SqueakSSL-Tests';
I downloaded the mentioned package, and it is just a dll file. I can't find anywhere on the net how you install a squeak plugin. I tried putting it in the VM and Image directories, but the squeakSSL tests fail.
How do you install a squeak plugin?
First, you have to download the DLL file and put it in your VM directory. Next, open a workspace in Squeak and run:
(Installer ss)
project: 'SqueakSSL';
install: 'SqueakSSL-Core';
install: 'SqueakSSL-Tests'.
This will install the appropriate Squeak classes necessary to access to plugin. This should be everything you need to do.
If it doesn't work, try checking the output of:
Smalltalk listLoadedModules
The SSL plugin should be listed after you tried running a test. If the plugin is listed, but the tests still fail it's probable that something -- either the Smalltalk classes or the binary plugin -- is outdated.