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).
Related
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.
Is there a way I can get autocomplete on VS Code for webdriverio?
Other code editors like Intellij provide something like Settings -> Preferences -> Languages & Frameworks -> JavaScript -> Libraries
From there we can add a directory with webdriverio commands
How can I do similar thing with VS Code?
my understanding is, vscode is built with typescript and by default it does not support autoComplete(Intellisense) on a package that is built with javascript. So all the js package creators would provide an #types file. These #types file help vscode to find all the function definitions, object properties. etc., etc., of your JS package and show as suggestions. Which in case here is webdriverio package.
So adding a #types dependency that is related to your JS package will mostly fix the issue.
i.e.,
npm install #types/webdriverio --save-dev
After adding the package, i started getting the browser object suggestions.
All the above works fine for v4 version of WDIO.
If you are using v5 version: Then as per their official documentation we need to create a jsconfig.json file on the root directory.
Above answer worked well :
you need to install below dependency :
if you are using webdriverio v4 (for cucumber BDD ) use below
npm install #types/webdriverio#4 --save-dev
or use :
npm install #types/webdriverio --save-dev
VSCode Intellisense
Using #types/webdriverio is not suggested by webdriverio and it is now deprecated:
npm WARN deprecated #types/webdriverio#5.0.0: This is a stub types definition. webdriverio provides its own type definitions, so you do not need this installed.
I would suggest to follow the official documentation by WebDriverIO here:
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.
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.