I have an application in Svelte that only works on versions above 84 of chrome, but I need it to work on older versions as well. Is there any way to solve this problem?
This depends on your build system and what the source of the problem is.
E.g. Vite has built-in support for transpiling to specific JS versions. However, if an API is missing, you have to add polyfills (e.g. via core-js).
Related
Recently I was create react app using vite , it is lightweight , less config and fast then compare with webpack . now my question is , is it required bable configuration in Vite project
No, vite does automatic syntax transforms but it only targets browsers that support es modules (firefox & chrome started supporting it around 2018). If you want to support new js features in older browsers you need to add polyfills though. You can read about the exact behavior and how to support even older browsers here.
I think that question need more information about that topic.
Vite.js uses the built-in JavaScript support of the browser, so you don't need to explicitly configure the JavaScript version in Vite.js itself.
When I said Vite.js uses the built-in JavaScript support of the browser, I meant that Vite.js relies on the JavaScript engine of the browser to interpret and run the JavaScript code in your application. The JavaScript engine is the component of the browser that executes JavaScript code. When you visit a web page that contains JavaScript, the browser runs the JavaScript code using its built-in JavaScript engine. This means that the version of JavaScript that is supported by your application is determined by the version of the JavaScript engine that is built into the browser. In the case of Vite.js, the JavaScript code in your application is not transpiled or otherwise modified before being run by the browser. However, if your application uses modern JavaScript syntax that is not supported by the target browsers, you will need to transpile the code to an older version of the language that is supported. In that case, you can use Babel.
No, it is already setup on the background. However if you'd like to adjust Babel's config you can do it. Read the docs here: https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/README.md
What module to use in tsconfig, commonjs or es6?
How to make desicion? I need that output module will work in client/back sides.
So here we are talking about the module option that will be used by typescript to determine what is the name of the module that will compile your code to the targeted version of javascript you specified with the option target.
So the underlying question you are asking is, what is my target ? Should I target ES3, ES5, ES6, ES7, ES8 or ... ES42 ?
Answer : the compatibility.
In 2020 you propably target ES5 or ES6 (which is the default value).
(You can ignore CommonJS because it relate to ES3 which is 99% chance irrelevant to you)
some article
If your code is made to be executed on browsers, I would recommand you to look which is the latest version supported by all your targeted browser and take the one that is supported by all.
Ex: Safari ES6, Firefox ES8, Chrome ES8 : so you choose ES6 as target so your code works on every targeted browser.
The website caniuse.com is usefull to know which features are supported and which are not
If your code is made to run on backend (node.js), look at which version of node.js is running. Every version of node have different capabilities.
You can have a look here
Additionnal materials :
What version of Javascript is supported in node.js
I have several backend-only Node.js projects which use a simple TypeScript config.
Before March 2018, I had this in package.json:
"devDependencies": {
"#types/core-js": "^0.9.46",
"#types/node": "^9.6.2"
}
since ~March 2018, I have been omitting "#types/core-js" and everything seems to compile fine. Do we need "#types/core-js" anymore?
I have several Node-based projects written in TypeScript. I never ever used #types/core-js in my projects. So it is definitely not necessary to use #types/core-js in order to write Node-based code. Having #types/node, on the other hand, is a boon if you're going to use Node's API.
The first thing to do if you run into a compilation issue that appears to be caused by the compiler not knowing about features introduced in ES6 is to set lib to load the proper typings you need. For instance, if you decide to target es5 but want to use methods, classes, functions introduced in ES6, you do need to specify "es6" in your lib setting because by default the target es5 loads the lib es5 too. (According to the documentation, a target of es5 sets lib by default to DOM,ES5,ScriptHost, whereas a target of es6 sets lib by default to DOM,ES6,DOM.Iterable,ScriptHost.)
I've run into some very rare cases where there's something missing in the es6 lib. In such cases, I just write a definition to fix that specific problem. Loading #types/core-js might also fix the issue, but it also contains a lot of other things that are not necessary, and it adds a dependency to the project, which then must be managed, etc. Not worth it.
The focus above was Node projects, but even in web-based projects where I have a dependency on core-js I don't use #types/core-js. As I see it, the presence of core-js in a project should be entirely transparent to the project's application code. I'm writing code made to run on any platform providing an API that conforms to ES6 or later, I'm not writing code made to run with core-js specifically.
You should only need #types/core-js if you're using something that is in that declaration that is not available in your TypeScript declarations for your major version. This is useful if you're expecting to use core JavaScript ES6 features that are in core-js but were not implemented in the version of TS you were using at the time. There's more information available on the TS GitHub related to your question but in all reality if you're just using ES stuff that's there now, no you shouldn't need it anymore.
edit: Before I had stated it as node, but in all possibilities since it's TS it probably didn't know how to compile to the target without the declaration. As of TS 2 and NodeJS 6 you shouldn't really need it anymore.
I would like to know whether it is possible to have third-party javascript libraries' source code available whilst debugging.
FYI, I use npm/nodejs and the angular CLI (which itself relies on Webpack).
Example libraries (together with their source languages) that I would like to have available during debugging are:
Angular 2 (typescript)
RxJS (typescript)
I guess what I want to achieve is related to configuring source maps.
Any comment or guidance welcome.
edit: Can someone please advise how to configure the angular CLI in order to have angular and RxJS typescript sources available whilst debugging?
Yes, to be able to set breakpoints in source files while debugging, you need sourcemaps. But this is not the thing that can be configured in the IDE, you need to set up your build tools accordingly. The only thing that should be configured on the IDE end is the run configuration - you might need to specify Remote URL mappings for your project directories
To complement lena's answer and as of #angular/cli version's 6.1 is it now possible to output source maps for vendor libraries using the following syntax:
ng serve --source-map --vendor-source-map
It also works for the ng build command.
See also: https://blog.ninja-squad.com/2018/07/27/angular-cli-6.1/
It is then possible to debug third-party libraries using an IDE or the browser.
I don't know with web apps if you still have to use Babel if Node 4 is out which supports ES6 so why would I need babel anymore for any web related code? Or maybe I don't?
I see most apps are using babel but I wonder if people are pulling it out now or is there middleware people typically use in web apps that still rely on it, thus you have to keep it and keep using babel?
Node v4 doesn't support the full feature set of ES2015 (aka ES6). For those that aren't supported you still can use Babel. You can find a list of node's support of ES2015 features in this page.
You say "web related code", which is too broad, but I assume you're interested in browser support as well. No browser supports all ES2015 features yet, so you should use a transpiler like Babel. You can find a table of feature compatibility here.
You will also find that no transpiler has full support either, so be careful when introducing new features.
It's not likely that projects will stop using transpilers yet. Even less so if they want to support older versions of node.