I recently created a Typescript Package that I would like to test in an app before publishing on NPM.
The entry file (index.ts) looks like this =>
import Builder from './core/builder';
export default Builder;
Basically, there is many files, but I want the user to just use a "static" class Builder that I export in the index. so the user can just do import Builder from 'builderts'
My package.json folder is the following
"name": "builderts",
"main": "./dist/builderts.js",
"types": "./dist/builderts.d.ts",
"files": [
"dist/*"
],
"scripts": {
"preversion" : "npm run lint",
"prepare": "npm run build",
"prepublishOnly": "npm test && npm run lint",
"version" : "npm run format && git add -A src",
"postversion" : "git push && git push --tags",
"build": "tsc",
"watch": "tsc-watch",
"format": "prettier --write \"src/**/*.ts\" \"src/**/*.js\"",
"lint": "eslint tsconfig.json"
},
and my tsconfig.json
{
"compilerOptions": {
"target": "es6", /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', or 'ESNEXT'. */
"module": "amd", /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
"declaration": true, /* Generates corresponding '.d.ts' file. */
"declarationMap": true, /* Generates a sourcemap for each corresponding '.d.ts' file. */
"sourceMap": true, /* Generates corresponding '.map' file. */
"outFile":"./dist/builderts.js", /* Concatenate and emit output to single file. */
"outDir": "dist", /* Redirect output structure to the directory. */
"strict": true, /* Enable all strict type-checking options. */
"esModuleInterop": true, /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
"forceConsistentCasingInFileNames": true /* Disallow inconsistently-cased references to the same file. */
},
"include": ["src"],
"exclude": ["node_modules", "dist"]
}
The problem I face is, I tried to create a small test project and install the module using
npm install absolute/path
it install correctly, but when I try to import the package using
import Builder from 'builderts';
I do not have neither autocompletion, and I have an error saying
File 'D:/User/Local/gitRepo/builderts/dist/builderts.d.ts' is not a module.
I do not quite understand what I am missing in the process.
Looks to me that you need to update the types in package.json
You stated above that the file name was index.ts, have you considered updating package.json ? :
{
...
"types": "./dist/index.ts",
...
}
Related
I have this import_map.json file:
{
"imports": {
"node_modules/" : "./node_modules"
}
}
at a high-level I am trying to create some compatibility for .ts files, for both Deno and Node.
My imports look like this:
import * as util from 'util';
import chalk from "node_modules/chalk";
When I run this:
deno run --import-map='import_map.json' ./src/linked-queue.ts
I get this loathsome error:
Import map diagnostics:
- Invalid target address "file:///.../linked-queue/node_modules" for package specifier "node_modules/". Package address targets must end with "/".
error: Blocked by null entry for ""node_modules/""
at file:///.../linked-queue/src/linked-queue.ts:4:19
Anyone know how to resolve this error?
"imports": {
"node_modules/" : "./node_modules/"
}
Add a trailing slash on the target specifier. See also the spec and the source.
The manual covers this scenario in the following three sections:
4.1 - Using npm packages with npm specifiers
4.3 - The std/node Library
4.4 - Using Import Maps
I'll show a reproducible example rather than copy + paste everything from the docs (because a few copied snippets aren't really enough; this is a multi-faceted issue) — however take note of the values in the import map, as they are derived by reading through all three linked sections of the documentation:
./import_map.json:
{
"imports": {
"chalk": "npm:chalk#5.2.0",
"node:util": "https://deno.land/std#0.170.0/node/util.ts"
}
}
./deno.jsonc:
{
"importMap": "./import_map.json",
"tasks": {
// I included these permissions (which are required by chalk) in advance to avoid needing to grant them one-by-one at runtime:
"dev": "deno run --allow-env=FORCE_COLOR,TF_BUILD,TERM,CI,TEAMCITY_VERSION,COLORTERM,TERM_PROGRAM,TERM_PROGRAM_VERSION src/linked-queue.ts"
}
}
./src/linked-queue.ts:
import * as util from "node:util";
import chalk from "chalk";
console.log('util:', typeof util); // util: object
console.log('chalk:', typeof chalk); // chalk: function
Running in the terminal using the defined task:
% deno --version
deno 1.29.1 (release, x86_64-apple-darwin)
v8 10.9.194.5
typescript 4.9.4
% deno task dev
Task dev deno run --allow-env=FORCE_COLOR,TF_BUILD,TERM,CI,TEAMCITY_VERSION,COLORTERM,TERM_PROGRAM,TERM_PROGRAM_VERSION src/linked-queue.ts
util: object
chalk: function
% echo $?
0
So far, everything is great in Deno.
Let's check to see that the same code works without modification in Node.js. The following files need to be added to compile and run using Node, since it doesn't include all of Deno's built-in tooling:
./package.json:
{
"name": "so-74905332",
"version": "0.1.0",
"type": "module",
"scripts": {
"compile": "tsc",
"dev": "tsc && node src/linked-queue.js"
},
"license": "MIT",
"dependencies": {
"chalk": "5.2.0"
},
"devDependencies": {
"#types/node": "^18.11.17",
"typescript": "^4.9.4"
}
}
./tsconfig.json:
Why these values? I'm just using a recommended base, linked to from the TS repo wiki:
// This file was autogenerated by a script
// Equivalent to a config of: strictest extends esm extends node18
{
"$schema": "https://json.schemastore.org/tsconfig",
"display": "Node LTS + ESM + Strictest",
"_version": "18.12.1",
"compilerOptions": {
"lib": [
"es2022"
],
"module": "es2022",
"target": "es2022",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true,
"moduleResolution": "node",
"allowUnusedLabels": false,
"allowUnreachableCode": false,
"exactOptionalPropertyTypes": true,
"noFallthroughCasesInSwitch": true,
"noImplicitOverride": true,
"noImplicitReturns": true,
"noPropertyAccessFromIndexSignature": true,
"noUncheckedIndexedAccess": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"importsNotUsedAsValues": "error",
"checkJs": true
}
}
Running in the terminal using the defined npm script:
% node --version
v18.12.1
% npm install
added 3 packages, and audited 4 packages in 1s
1 package is looking for funding
run `npm fund` for details
found 0 vulnerabilities
% npm run dev
> so-74905332#0.1.0 dev
> tsc && node src/linked-queue.js
util: object
chalk: function
% echo $?
0
The same module source code also works in Node.js.
I am using swc to transpile my Typescript code on a side project and am struggling ignoring the tests files from the final output using the cli --ignore option.
lib versions:
#swc/cli: ^0.1.57
#swc/core: ^1.2.173
command:
swc ./src --out-dir dist --ignore **/*.test.ts
.swrc config
{
"jsc": {
"target": "es5",
"paths": {
"#src/*": ["./src/*"]
},
"parser": {
"syntax": "typescript",
"decorators": true,
"dynamicImport": true
}
},
"minify": true,
}
I still saw all tests files in my dist output folder. Note that using the exclude property in the .swcrc like this "exclude": [".*\\.spec|test\\.(j|t)s$", "mocks", "types"] works, but how is the --ignore arg supposed to be used ?
Typescript doesn't recognize the express.json() function although many tutorials state this code should compile as it is.
Is there something I have done wrong?
Example tutorial where this is stated to be working: https://auth0.com/blog/node-js-and-typescript-tutorial-build-a-crud-api/#test-the-express-api-endpoints
Moreover I know this works in normal Node.js but have never tried it in Typescript.
const version = require('../package.json').version;
import express from 'express';
console.log("Application is running on version " + version);
const app = express();
app.use(express.json());
app.listen(7777);
Compiler output:
app.ts:10:17 - error TS2339: Property 'json' does not exist on type 'Express'.
10 app.use(express.json());
~~~~
Found 1 error.
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! test#1.0.0 start: `tsc --outDir dist && node dist/app.js`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the test#1.0.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\name\AppData\Roaming\npm-cache\_logs\2021-07-15T14_34_22_294Z-debug.log
tsconfig.json
{
"compilerOptions": {
/* Visit https://aka.ms/tsconfig.json to read more about this file */
/* Basic Options */
// "incremental": true, /* Enable incremental compilation */
"target": "es5", /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', 'ES2021', or 'ESNEXT'. */
"module": "commonjs", /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
// "lib": [], /* Specify library files to be included in the compilation. */
// "allowJs": true, /* Allow javascript files to be compiled. */
// "checkJs": true, /* Report errors in .js files. */
// "jsx": "preserve", /* Specify JSX code generation: 'preserve', 'react-native', 'react', 'react-jsx' or 'react-jsxdev'. */
// "declaration": true, /* Generates corresponding '.d.ts' file. */
// "declarationMap": true, /* Generates a sourcemap for each corresponding '.d.ts' file. */
// "sourceMap": true, /* Generates corresponding '.map' file. */
// "outFile": "./", /* Concatenate and emit output to single file. */
// "outDir": "./", /* Redirect output structure to the directory. */
// "rootDir": "./", /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
// "composite": true, /* Enable project compilation */
// "tsBuildInfoFile": "./", /* Specify file to store incremental compilation information */
// "removeComments": true, /* Do not emit comments to output. */
// "noEmit": true, /* Do not emit outputs. */
// "importHelpers": true, /* Import emit helpers from 'tslib'. */
// "downlevelIteration": true, /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
// "isolatedModules": true, /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */
/* Strict Type-Checking Options */
"strict": true, /* Enable all strict type-checking options. */
// "noImplicitAny": true, /* Raise error on expressions and declarations with an implied 'any' type. */
// "strictNullChecks": true, /* Enable strict null checks. */
// "strictFunctionTypes": true, /* Enable strict checking of function types. */
// "strictBindCallApply": true, /* Enable strict 'bind', 'call', and 'apply' methods on functions. */
// "strictPropertyInitialization": true, /* Enable strict checking of property initialization in classes. */
// "noImplicitThis": true, /* Raise error on 'this' expressions with an implied 'any' type. */
// "alwaysStrict": true, /* Parse in strict mode and emit "use strict" for each source file. */
/* Additional Checks */
// "noUnusedLocals": true, /* Report errors on unused locals. */
// "noUnusedParameters": true, /* Report errors on unused parameters. */
// "noImplicitReturns": true, /* Report error when not all code paths in function return a value. */
// "noFallthroughCasesInSwitch": true, /* Report errors for fallthrough cases in switch statement. */
// "noUncheckedIndexedAccess": true, /* Include 'undefined' in index signature results */
// "noImplicitOverride": true, /* Ensure overriding members in derived classes are marked with an 'override' modifier. */
// "noPropertyAccessFromIndexSignature": true, /* Require undeclared properties from index signatures to use element accesses. */
/* Module Resolution Options */
// "moduleResolution": "node", /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
// "baseUrl": "./", /* Base directory to resolve non-absolute module names. */
// "paths": {}, /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
// "rootDirs": [], /* List of root folders whose combined content represents the structure of the project at runtime. */
// "typeRoots": [], /* List of folders to include type definitions from. */
// "types": [], /* Type declaration files to be included in compilation. */
// "allowSyntheticDefaultImports": true, /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
"esModuleInterop": true, /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
// "preserveSymlinks": true, /* Do not resolve the real path of symlinks. */
// "allowUmdGlobalAccess": true, /* Allow accessing UMD globals from modules. */
/* Source Map Options */
// "sourceRoot": "", /* Specify the location where debugger should locate TypeScript files instead of source locations. */
// "mapRoot": "", /* Specify the location where debugger should locate map files instead of generated locations. */
// "inlineSourceMap": true, /* Emit a single file with source maps instead of having a separate file. */
// "inlineSources": true, /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */
/* Experimental Options */
// "experimentalDecorators": true, /* Enables experimental support for ES7 decorators. */
// "emitDecoratorMetadata": true, /* Enables experimental support for emitting type metadata for decorators. */
/* Advanced Options */
"skipLibCheck": true, /* Skip type checking of declaration files. */
"forceConsistentCasingInFileNames": true /* Disallow inconsistently-cased references to the same file. */
}
}
Check the version of your devDependencies.
It should look something like that.
"devDependencies": {
"#types/express": "^4.17.12",
}
The problem could be identified in the package.json file.
Somehow the version of the #types/express package was defined with the version "github:types/express" which seems not to be the most current.
The fix was to update the package.json file from
{
"name": "test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "tsc --outDir dist && node dist/app.js",
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"#types/body-parser": "^1.19.1",
"body-parser": "^1.19.0",
"express": "^4.17.1",
"tslint": "^6.1.3"
},
"devDependencies": {
"#types/express": "github:types/express",
"#types/node": "^16.3.2",
"ts-node": "^10.1.0",
"ts-node-dev": "^1.1.8",
"typescript": "^4.3.5"
}
}
to (only the version of "#types/express" has been changed)
{
"name": "test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "tsc --outDir dist && node dist/app.js",
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"#types/body-parser": "^1.19.1",
"body-parser": "^1.19.0",
"express": "^4.17.1",
"tslint": "^6.1.3"
},
"devDependencies": {
"#types/express": "^4.17.12",
"#types/node": "^16.3.2",
"ts-node": "^10.1.0",
"ts-node-dev": "^1.1.8",
"typescript": "^4.3.5"
}
}
changing from import express from 'express' to import * as express from 'express' did it for me
I'm using typescript v^3.4.2, in an express app (^4.14.1), using node v11.3.0.
When I run my build for typescript, I get the following error:
Could not find a declaration file for module 'vimeo'. '/Users/me/Code/MyServer/node_modules/vimeo/index.js' implicitly has an 'any' type.
Try `npm install #types/vimeo` if it exists or add a new declaration (.d.ts) file containing `declare module 'vimeo';`
1 import { Vimeo } from "vimeo";
I am using the Vimeo api client for nodejs vimeo.js, version 2.1.1.
I've attempted to run yarn add --dev #types/vimeo, but unfortunately that library is for the other vimeo library, vimeo/player.js. Installing it is of no use.
I've tried to follow this article on creating my own custom type declaration.
Here is my tsconfig.json:
{
"compilerOptions": {
"module": "commonjs",
"esModuleInterop": true,
"target": "es6",
"noImplicitAny": true,
"moduleResolution": "node",
"sourceMap": true,
"outDir": "dist",
"baseUrl": ".",
"paths": {
"*": ["node_modules/*"]
},
"typeRoots": ["./types", "./node_modules/#types"]
},
"include": ["src/**/*", "controllers/**/*", "routes/**/*", "models/**/*"],
"exclude": ["node_modules", "types"]
}
And I've created: /Users/me/Code/MyServer/types/vimeo/vimeo.d.ts, which contains:
declare module vimeo {}
When I add that the error changes to:
yarn run v1.15.2
$ yarn build
$ tslint -c tslint.json -p tsconfig.json --fix
$ tsc
error TS2688: Cannot find type definition file for 'vimeo'.
The article also suggests adding a root global.d.ts with the same definition in it, but that has no effect.
I'm stumped. Any help would be appreciated.
(This is my package.json scripts block:)
"main": "dist/app.js",
"scripts": {
"prebuild": "tslint -c tslint.json -p tsconfig.json --fix",
"build": "tsc",
"prestart": "yarn build",
"start": "babel-node dist/app.js --presets es2015",
"test": "echo \"Error: no test specified\" && exit 1"
},
And here's my tslint.json:
{
"defaultSeverity": "error",
"extends": ["tslint:recommended"],
"jsRules": {},
"rules": {
"trailing-comma": [false],
"curly": [true, "ignore-same-line"],
"ban-types": false
},
"rulesDirectory": []
}
If I recall correctly, setting "noImplicityAny": false, can solve the issue of declaration files... or you can look for some .d.ts for that module (or even make your own and do a pull request in GitHub)
How can I compile my Typescript project into a TS compilation so I can then import it into other TS projects and use the type definitions? For backward compatibility, I also want to export them as pure JS too so others who don't use TS, can still use the project.
You need to publish your project as an npm package. You can create a private package on npm if you want (but you need a paid account for that), or you can publish it publicly, or you can use sinopia, which is basically a local instance of npm.
Any one of these options requires you to have an up to date package.json file that specifies your project's dependencies.
You will be publishing your package in compiled form. So, if you specify your tsconfig and package.json properly, you will be exporting js files along with d.ts. files and the package will be usable either by typescript or vanilla javascript.
This is how I've done it:
// package.json
// The property name: #my-org/... means that the package is scoped -
// you can point a #scope at a specific NPM registry.
// See https://docs.npmjs.com/misc/scope
// We use myget.org to host our private packages.
{
"name": "#my-org/ng-lib",
"version": "1.0.8",
"main": "dist/index.js",
"scripts": {
"transpile": "tsc --outDir ./",
"clean": "rimraf ./services && rimraf ./*.js && rimraf ./*.d.ts"
},
"author": "*** <me#my-org.com>",
"license": "ISC",
"files": [
"**/*.js",
"**/*.d.ts"
],
"typings": "index.d.ts",
"dependencies": {
"#types/angular": "^1.5.20",
"angular": "^1.5.9"
},
"devDependencies": {
"rimraf": "^2.5.4"
}
}
EDIT:
Notice the "typings": "index.d.ts" line? That describes the main "types" file for the package. So when you do an import * as ngLib from '#my-org/ng-lib' it will use the typings from node_modules/#my-org/ng-lib/index.d.ts for intellisense, and upon transpile webpack will find the main js file at node_modules/#my-org/ng-lib/dist/index.js
So if you've created an index.d.ts by hand and all you've got to export are interfaces you can point the typings field at that index.d.ts as interfaces have no implementation, and just describe the shape of an object.
However, if you've got objects with logic (methods, getters/setters, etc) they will more than likely be classes, which you'll need to transpile down to .js AND .d.ts files.
EXAMPLE:
./index.ts # Re-exports both my-class and my-interface
./my-class.ts # Implements my-interface.d.ts
./my-interface.d.ts
This output of this after transpile should be as follows in a "typed" NPM package:
./index.d.ts
./index.js
./my-class.js
./my-class.d.ts
./my-interface.d.ts
And package.json will include the following lines:
"main": "./index.js",
"typings": "./index.d.ts",
"files": [
"./index.d.ts",
"./index.js",
"./my-class.js",
"./my-class.d.ts",
"./my-interface.d.ts"
]
... and when consuming the package (once it's published and installed in another project) can be done in the following ways:
import * as ngLib from '#my-org/ng-lib'
import { MyClass } from '#my-org/ng-lib'
import { MyInterface } from '#my-org/ng-lib'
import { MyClass } from '#my-org/ng-lib/my-class'
import { MyInterface } from '#my-org/ng-lib/my-interface'
END EDIT
The declaration property in tsconfig.json will emit .d.ts files describing the 'shape' of your exported objects.
// tsconfig.json
{
"compilerOptions": {
"target": "es5",
"module": "commonjs",
"sourceMap": false,
"emitDecoratorMetadata": true,
"declaration": true,
"experimentalDecorators": true,
"removeComments": true,
"noImplicitAny": false,
"suppressImplicitAnyIndexErrors": false,
"baseUrl": "./src",
"listFiles": true,
"noImplicitUseStrict": false
},
"exclude": [
"node_modules"
]
}
And if it's a complicated package, I'll have separate modules and aggregate them in the index.ts like so:
// index.ts
export * from './module-one'
export * from './module-two'
export * from './module-three'
You can also have sub-directories, each with their own indexes.
This will create both the index.js and index.d.ts files, which allows the following:
import * as ngLib from '#my-org/ng-lib'
import { ModuleOne } from '#my-org/ng-lib/module-one'
import { SubModuleOne } from '#my-org/ng-lib/submodules/submodule-one'