Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 days ago.
Improve this question
I came across the NPM package called expect being used alongside the jest package in a package.json file.
It is also from the Jest team, but it is hard to find in the docs why you would want to use it on its own. Is it necessary to run Jest tests? Is it for TypeScript users?
Can anybody provide context why you would want to use it in addition to the jest package?
I don’t know their reason for separating out the package by itself. Perhaps to break up their own repo. Maybe to make it usable by other frameworks. I know Playwright uses it to basically extend or build their assertions on top of it.
That being said, unless you plan on building a new test runner/framework or somehow extending it, then you probably don’t need it yourself. It’s already built in/depended on and provided by those frameworks, so you wouldn’t need it in addition.
I’m not sure why it was in your project, but I’d say it’ll likely be pretty obvious if it was needed if you remove it and tests start breaking. Theoretically if it is somehow used (which again seems unlikely since jest already includes it), it should only be for testing, so there really should be no risk in just removing it and seeing if they still work.
Hope that helps!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
A coworker of mine recently setup testing in a new project (a JS library) where a transform step hooks in to the babel config for Webpack in the production config.
For reference, this is the setting used with Jest: https://jestjs.io/docs/en/configuration.html#transform-object-string-string
The production build targets ES5, while our CI is on Node 10 and up. This means that, for all of our tests, the source code is getting transformed by all the unnecessary Babel transforms. Mind you, our source code is regular ES2016 Javascript, nothing too fancy. The only transform required might be the ES6 import syntax.
My gut reaction was that this was quite wasteful and unnecessarily couples the tests to the production build config. But my coworker's justification was that he wants to make sure that the tests run against the same artifacts that users will be using.
That makes a lot of sense to me, but I am not sure what the right answer is. What are the pros and cons of each approach? What are the dangers of running your tests against the production build transforms?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I know a lot of people use the word "compile" quite loosely and interchangeably but I was hoping someone could explain to me like I'm 5 if it's technically incorrect to call a JS module bundler (eg. Webpack) a compiler or a build tool? I often hear things like "you have to compile your JS in order to update your bundle".
Thanks in advance.
It's definitely a build tool, and one which can be automated. One of the main use cases is to bundle various javascript sources into one or several bundle(s) of javascript, which is generally referred to as 'transpiling'. Transpiling basically means the output is the same language as the input, ie javascript in javascript out. Compiling is generally the act of turning source code into machine language, or IL. Webpack can of course also bundle other things, which is why on their own webpage they refer to it as a bundler.
In a colloquial sense, people often mean 'compile' to be the same as 'build', in the sense that you run your build tool.
Webpack it is a build tool.
Maybe you heard some like "some node package could not compiled for your OS" like
node-sass module. This module compliled from source code
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Several projects include its source code in the NPM distribution package bundle. For instance, React includes its unminified/unbuilt javascript files in a lib folder but it also has a dist folder with the built files.
Is this a good practice ?
On the downsides I think it increases the time the package will take to be downloaded and the disk consumption.
(that's why I usually add source code folders to the .npmignore file)
But I ask myself, why so many libraries do so ? Which are the advantages ?
I'm not sure if this question really falls under something that's asked here on SO, mostly because it's opinion based and could be more of a discussion. But here are my 2 cents anyways:
I believe most of these libraries add their source code (partially because they're open source) to help with debugging purposes. They are typically (but not always) bundled with a .map file as well. Conveniently there's a post that explains what a map file is..
If you think about it like this: anyone who is using your distribution will really only need to install it "once", as in they will probably not be installing it every time they want to use it, but just when they either want to cleanly deploy their project or simply when they install it.
Another thing to think about is: how large is your distribution? Will it really be so big that it will slow down installation time?
As for space a few MB will be negligent on pretty much any modern machine.
I personally think that it's good practice to include the source code as well, I like to know how libraries do what they do, and I like being able to have the option to look into why my code may cause the library to throw errors. But I'm sure there are good reasons not to as well.
tl;dr
They do it to help developers debug
Unless your project really takes a long time to install, don't worry about it
Unless your project is super big, don't worry about it
As a dev I like it when projects include it, but "good practice" is quite opinionated and it depends on the situation
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have a question want to ask you guys .... Recently i found out Node.js plus Socket.io can make a good real time web . But what i scare is what happened if one day Socket.io gone ? Like if the Author unpublished the module or what ever happened that module is gone so all the project depending on that module is down too ? Please answer me i know maybe this is stupid question for some of your guys ... but that what i scare about and i don't know if it gonna happened or before have any module is gone somehow then Project of people depending on it is suck after that anything like that happened before ?? . I just want to know what i gonna do if it happened .. and will it happened ? Thanks
All node modules are installed locally on your machine/server. You use the npm tool to do that automatically for you. See https://npmjs.org/doc/cli/npm.html
Even if a module gets deleted from the registry and nowhere to be found on the internet, it is still on your project unless you delete it yourself.
The worst thing that could happen is that there wouldn't be more updates/support/bug fixes for that specific module. But aside from that, the module is installed in your own project so what was working for you will still work.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I know it is a weird question, but wanted clarification nevertheless.
Assume there is an application and the testing team has access to this application only through a URL, with no access to the codebase.
My question is, can one write say jasmine test cases without access to a code base by only using the URL.
PS: My opinion is that it is not possible, because I think it doesn't fit the idea behind which most of these testing frameworks are created.
When accessing the app by URL, does the team have any access to inputs/controls of the app? If so, they can write test cases using something like SilkTest instead. I haven't used Jasmine, but it looks as if it tests actual code itself, rather than doing automated testing on the app as if it were a user. In that case, if your code on the URL is obfuscated or encrypted, then no, they can't test it. If it's plain Javascript code, then they can see it all right in the browser, and write test cases based on that.