The execution time of a simple ts-node --version needs a long time
I have a fresh virtual maschine (xen, 20GB RAM, lots of free space) with ubuntu 18.04 server. node/npm installed via package manager. Unfortunately the execution of a simple ts-node --version needs really long time to finish:
time ./node_modules/.bin/ts-node --version
ts-node v7.0.1
node v8.10.0
typescript v3.6.4
cache "/tmp/ts-node-94a6b447580330f9f2b609422537b04239ff3a39df9137e32efd559f1a2935cb/9d1b7d973ebcaeec54cd97f2de9eb4549430f03609c30b1504d897556bb2d5af"
real 2m44,511s
user 0m32,442s
sys 0m19,245s
Using a local virtual maschine (ubuntu 18.04 but virtual box and only 6GB RAM) the same request needs under a second:
time ./node_modules/.bin/ts-node --version
ts-node v7.0.1
node v8.10.0
typescript v3.6.4
cache "/tmp/ts-node-1da900a950c0ee3f0f80ae0bb561a80b80e89de692835d79984eb12d0a2f2a44/ca51062b04b699dcb91ec472983c8d598ee9fb43791553c229cba71256858f5a"
real 0m0,918s
user 0m0,840s
sys 0m0,083s
./node_modules/.bin/ts-node --help is really fast.
If I look in ./node_modules/.bin/ts-node (link to ../ts-node/dist/bin.js) the following prodecure is the problem:
var service = index_1.register({
files: argv.files,
pretty: argv.pretty,
typeCheck: argv.typeCheck,
transpileOnly: argv.transpileOnly,
cache: argv.cache,
cacheDirectory: argv.cacheDirectory,
ignore: argv.ignore,
project: argv.project,
skipIgnore: argv.skipIgnore,
skipProject: argv.skipProject,
compiler: argv.compiler,
ignoreDiagnostics: argv.ignoreDiagnostics,
compilerOptions: index_1.parse(argv.compilerOptions) || index_1.DEFAULTS.com
pilerOptions,
readFile: isEval ? readFileEval : undefined,
fileExists: isEval ? fileExistsEval : undefined
});
I use following tsconfig.json:
{
"compilerOptions": {
"module": "commonjs",
"declaration": true,
"removeComments": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"target": "es6",
"sourceMap": true,
"outDir": "./dist",
"baseUrl": "./",
"esModuleInterop": true
},
"exclude": ["node_modules"]
}
fresh npm install
Versions:
node --version
v8.10.0
npm --version
3.5.2
Maybe someone has an idea...
just found the reason for this strange behaviour:
the project-directory included a link to a huge image-directory with 100k+ image-files. If I remove the link, everything works as expected.
Thanks!
Related
Locally, my project works without errors, but after I deployed the project on Heroku, the following error occurred:
Again, everything is fine locally. Here is eslintrc.json:
{
"env": {
"browser": true,
"es2021": true
},
"extends": ["eslint:recommended", "google"],
"parser": "#typescript-eslint/parser",
"parserOptions": {
"ecmaFeatures": {
"jsx": true
},
"ecmaVersion": 12,
"sourceType": "module"
},
"plugins": ["react", "#typescript-eslint"],
"rules": {
"camelcase": "off",
"object-curly-spacing": "off",
"linebreak-style": 0,
"isolatedModules": 0,
"indent": "off",
"require-jsdoc": "off",
"max-len": "off",
"no-unused-vars": "off",
"no-invalid-this": "warn",
"operator-linebreak": "off"
},
"globals": {
"google": "readonly",
"process": "readonly",
"arrow-parens": "off"
}
}
You usually don't need ESlint in production. It's a good practice to verify your code with a linter while in a development mode. Regarding production, in pretty much all the cases, it makes sense to disable it.
That's why even the official documentation of ESlint recommends installing it with the --dev flag (https://eslint.org/docs/user-guide/getting-started):
yarn add eslint --dev
In that case, ESlint will be added to the "devDependencies" of your package.json.
Now, let's get back to the error. I guess, you deploy your app through:
yarn install --production
yarn build
(or npm analogy of these commands)
It doesn't matter if it's run on a host or in a docker container. The point is that before running these commands, you need to set the environment variable DISABLE_ESLINT_PLUGIN to true.
Try
export DISABLE_ESLINT_PLUGIN=true
yarn install --production
yarn build
if you deploy your app right on the host.
Or do this:
ENV DISABLE_ESLINT_PLUGIN true
RUN ["yarn", "install", "--production"]
RUN ["yarn", "build"]
if your app is dockerised.
In Visual Studio 2017, I am trying to use ES2015 Promises. Using TypeScript 2.1.5. I have a a tsconfig.json file in the solution, and it looks like this:
{
"compilerOptions": {
"noImplicitAny": false,
"noEmitOnError": true,
"removeComments": false,
"sourceMap": true,
"target": "es5",
"outFile": "outfile.js",
"lib": [ "dom", "es2015.promise", "es5" ]
},
"exclude": [
"node_modules",
"wwwroot"
]
}
I compile, and I get typings errors, for example:
error TS2339: Build:Property 'then' does not exist on type
'Promise'.
When I go to the error, I have intellisense showing it does in fact recognize the then function,and I can right click, go to definition, which takes me to lib.es2015.promise.d.ts.
Why does design time work and compile time does not, and how do I fix?
The tsconfig.json property called libs – link to dreadful official tsconfig documentation here – just provides typings so that, for example, your development environment can go to the type definition, infer types and auto-complete code. It does not shim the implementation of those classes into your built-in JS code; in many cases, the target environment (eg. the browser) provides its own implementation of Promise, so it's unnecessary. Shimming is a responsibility left to the developer :(
Here's how to provide Promise which even compiles down to ES3...
Step 1: Install a shim that provides Promise
In your project root, run this command (assuming you have a package.json there):
npm install --save es6-promise
Step 2: Make it available to your code
Add this line to any .ts file that uses a Promise:
import {Promise} from 'es6-promise';
Step 3: Make your tsc compiler aware of the typings
I'll be editing your current tsconfig.json file here:
{
"compilerOptions": {
// I've moved "noImplicitAny" to below.
"noEmitOnError": true,
"removeComments": false,
"sourceMap": true,
"target": "es3", // We can target ES3 with this method, if we want!
"outFile": "outfile.js",
/* From http://stackoverflow.com/a/32410515/5951226 : part of this block adds support for ES6 Promises */
"noImplicitAny": false,
"declaration": false,
"module": "commonjs",
"noLib": false
},
"exclude": [
// "node_modules", // We'll need to include "node_modules/es6-promise", so I'll leave it to you to play around with your inclusions/exclusions which are unique to your own use case.
"wwwroot"
]
}
If you really do need to exclude node_modules (which I think is an uncommon use case – surely you can get around this..?), you can move the es6-promise library to a separate location and import specifically from that location instead of using the automatic module resolution.
I'm using aurelia with typescript and I wanted to avoid using relative import path like :
import { DialogBox } from '../../resources/elements/dialog-box';
but rather
import { DialogBox } from 'resources/elements/dialog-box';
I modified my tsconfig.json so the compiler handles relative paths by adding baseUrl and paths like this:
"compilerOptions": {
"sourceMap": true,
"target": "es5",
"module": "amd",
"declaration": false,
"noImplicitAny": false,
"removeComments": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"moduleResolution": "node",
"lib": ["es2015", "dom"],
"baseUrl": ".",
"paths": {
"*":["src/*"]
}
}...
But when I run the cli's command 'au run --watch', I can see all steps working fine up to the writeBundle step that fails when tracing some files:
Starting 'processMarkup'...
Starting 'processCSS'...
Starting 'configureEnvironment'...
Finished 'configureEnvironment'
Starting 'buildTypeScript'...
Finished 'processCSS'
Finished 'processMarkup'
Finished 'buildTypeScript'
Starting 'writeBundles'...
The process fails with the following error:
Tracing resources/elements/dialog-box...
{ uid: 11,
name: 'writeBundles',
branch: false,
error:
{ [Error: ENOENT: no such file or directory, open 'C:\...\src\resources\elements\dialog-box.js']
errno: -4058,
The strange thing is: there are other files that are referenced with non-relative path and where the bundler doesn't fail.
And another strange thing: if I leave the relative path and bundle using the watcher, everything works fine. Then if I remove the relative '../../' from the problematic import, I get a bundling warning but everything works anyway...
Any idea what I might have done wrong?
EDITED FOR CORRECTION:
I just understoof why some files seemed to be bundled while others were not. I noticed that all the files with "root-relative" imports that didn't fail were actually imported from other files with a relative path. So I suppose the bundler finds them from there. That solves one thing but the base problem is still there : aurelia-cli fails bundling when there are "root-relative" imports...
EDITED FOR SOLUTION:
Thanks to the solution of Sinan Bolel here under, the relative path problem was solved by updating some packages:
npm i -D gulp-typescript#^3.1.5 typings#^2.1.0 aurelia-tools#^1.0.0
The semantic errors I got afterward came from some typings that were still installed and not needed as well as having typescript installed as a local npm package as well as globally.
I uninstalled them and all errors disappeared.
npm uninstall #types/es6-promise
npm uninstall #types/es6-collections
npm uninstall typescript
Take a look at this Gist example in which:
I create a class Init in src/lib/init.ts
I import init from 'lib/init' in src/main.ts without a relative path
I change main.ts to import environment from 'environment' as opposed to from './environment' -- which also works.
Using the original tsconfig generated by the CLI, my build failed with the error:
src/main.ts(3,18): error TS2307: Cannot find module 'lib/init'.
After changing to the tsconfig in my Gist, the build succeeded.
(invalid) Suggestions:
In tsconfig, can you please try:
a) Adding ./ ahead of src in compilerOptions.paths (this solves the issue on my machine)
paths: {"*": ["./src/*"]}
^
b) Adding filesGlob
"filesGlob": [
"./src/**/*.ts",
"./test/**/*.ts",
"./typings/index.d.ts",
"./custom_typings/**/*.d.ts"
],
edit: Previous suggestions did not work, how about updating packages:
npm i -D gulp-typescript#^3.1.5 typings#^2.1.0 aurelia-tools#^1.0.0
See results in https://github.com/aurelia/cli/issues/494#issuecomment-282103289
Comparing this to Visual Studio Code all you need to do is allow source maps and VSCode will debug TypeScript however I can't achieve the same on WebStorm.
I can easily debug server side JavaScript in WebStorm but not TypeScript
For anyone else wrestling with debugging TypeScript in WebStorm/IDEA, I had similar frustrations as OP (possibly for different reason). My issue was simply that I didn't set the working directory to the dist folder in the node run configuration. I am running tests in Jest and assumed the working dir should be the root of my project. Set it to dist and debugging started working!
Further info...
Source .ts files in src
Typescript version: 2.0.3
File tsconfig.json:
{
"compilerOptions": {
"jsx": "react",
"module": "commonjs",
"noImplicitAny": false,
"outDir": "dist",
"preserveConstEnums": true,
"removeComments": true,
"sourceMap": true,
"target": "es6",
"moduleResolution": "node"
},
"exclude": [
"node_modules",
"dist"
]
}
Jest config (in package.json):
"jest": {
"scriptPreprocessor": "<rootDir>/node_modules/ts-jest/dist/preprocessor.js",
"testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx)$",
"moduleFileExtensions": [
"ts",
"tsx",
"js"
]
}
Run configuration...
Working directory: <project_root>/dist
Javascript file: ../node_modules/jest-cli/bin/jest.js
Application params: --runInBand
Hope it helps!
was trying to find a way to let Webstorm/Intellij to watch the TS file change and restart server in debug mode. Looks like ts-node-dev which IHMO is faster than nodemon in terms of live-reload because it shares Typescript compilation process between restarts.
npm i ts-node-dev --save-dev
Then in your Run/Debug Configuration, add a node.js config with below params:
JavaScript file ---> node_modules/ts-node-dev/lib/bin.js
Applicationi parameters ---> --respawn -- src/script/local.server.ts
Now save the config and run with Debug, you should be able to set break point as well as live reload server on any TS code change.
I wrapped up a small library for this if you happen to develop with aws lambda
https://github.com/vcfvct/ts-lambda-local-dev
Just want to add what worked for me with Webstorm 2021.1.1
I found the easiest way is to go to your package.json and right click the green triangle next to the npm script you want to run. Then select debug.
I am able to apply the breakpoints to my typescript code and it works perfectly. Coming from .Net where it was always pretty straight forward to debug, I am glad to see webstorm making it just as simple.
This is my npm script that I choose to debug.
"dev": "env-cmd -f ./config/dev.env concurrently -k -n COMPILER,NODEMON -c gray,blue \"tsc -w\" \"nodemon -w dist dist/index.js\"",
I'm using a specific version of node called ts-node.
First add in your package.json file:
"devDependencies": {
"ts-node": "8.1.0",
"typescript": "3.2.4"
},
Run npm install and the node_module/.bin/ directory will include the ts-node or ts-node.cmd required for Windows.
Obviously these versions will move. You may see inside the package.json of ts-node project which version of typescript they are using to be the closest as possible.
Then you can add breakpoints. The only downside I see is that you must define the Javascript file (which is a ts file) into the configuration, instead of just right-click + run.
If you have the xyz is not a function error, check that your tsconfig.json file doesn't have "noEmit": false,
For running WebStorm(2017.2.3) debugger around typescript sources I did:
Setup Node.js configuration:
Working directory: root/of/the/project (where located my package.json)
JavaScript file: dist/index.js
I am compiling my TypeScript with gulp-typescript, but more important the source-map files. So for compiling was used task like below:
const gulp = require('gulp');
const ts = require('gulp-typescript');
const sourcemaps = require('gulp-sourcemaps');
const merge = require('merge2');
const tsProject = ts.createProject('tsconfig.json', {
declaration: true,
typescript: require('typescript'),
});
gulp.task('default', () => {
const result = gulp.src('./app/**/*.ts')
.pipe(sourcemaps.init())
.pipe(sourcemaps.identityMap()) // optional
.pipe(tsProject());
return merge([
result.js
.pipe(sourcemaps.write('.', { includeContent: false, sourceRoot: '../app' }))
.pipe(gulp.dest('dist')),
result.dts
.pipe(gulp.dest('dist')),
]);
});
All source TS files located in './app' folder, all compiled files located in ./dist folder. Most important source-files option sourceRoot, wrong value not bring you to ts file.
By sourcemaps.write('.', { includeContent: false, sourceRoot: '../app' } I am writing my .map files beside .js files and make reference to app folder. I no need content in .map files because it's already there (app folder).
Thanks to #Ekaterina I was able to run Node debug with Typescript.
I downloaded this vagrant selenium grid setup from GitHub, and tried it out as is. I can get my protractor tests working with the default firefox instances, but I am getting errors when trying to test on the chrome instances. Here is the log output from the node vm's node.log file when I try to run a test with chrome.
I have tried using openjdk 6 & 7, and have tried the latest chromedriver (64Bit) as well as chromedriver 2.9 & 2.8, and tried the latest versions of the selenium-sever-standalone jar file.
I am using protractor 0.23.1 at the moment. Here is my protractor config file:
exports.config = {
seleniumAddress: 'http://localhost:4444/wd/hub',
chromeOnly: false,
splitTestsBetweenCapabilities: true,
specs: ['./e2e/**/*pec.js'],
multiCapabilities: [{
'browserName': 'firefox',
'platform': 'LINUX',
'maxInstances': 2,
}, {
'browserName': 'chrome',
'platform': 'ANY',
'maxInstances': 2
}],
jasmineNodeOpts: {
showColors: true,
isVerbose: true,
includeStackTrace: true,
defaultTimeoutInterval: 30000
}
};
I have also tried adding the flags below to the script in the conf/upstart/selenium-node.conf file, but chrome still wont startup (same message as in log above).
-browser "browserName=chrome" -Dwebdriver.chrome.driver="/usr/bin/chromedriver"
Does anybody have this setup running with chrome? Or can you see what the problem is here? Any advice could be helpful.
Try opening an issue in that selen repository since the provided vagrant doesn't seem to work out of the box.
Overall seems your goal here is to run selenium+chrome headless.
Take a look at my answer here.