There is a similar post here:
My custom NPM Package is not found,
but that did not resolve my issue.
Could not find a declaration file for module '#dc_microurb/common'.
'/Users//Projects/ticketing/auth/node_modules/#dc_microurb/common/build/index.js'
implicitly has an 'any' type. Try npm install #types/dc_microurb__common if it exists or add a new declaration
(.d.ts) file containing `declare module '#dc_microurb/common';
There is no #types/dc_microurb__common and I am unclear as to why it is suggesting to create a new .d.ts file, when that happens automatically during the build process.
This is the package.json file inside my published package:
{
"name": "#dc_microurb/common",
"version": "1.0.5",
"description": "",
"main": "./build/index.js",
"types": "./build/index.d.ts",
"files": [
"./build/**/*"
],
"scripts": {
"clean": "del ./build",
"build": "npm run clean && tsc",
"pub": "git add . && git commit -m \"Updates\" && npm version patch && npm run build && npm publish"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"del-cli": "^3.0.1",
"typescript": "^4.0.5"
},
"dependencies": {
"#types/cookie-session": "^2.0.41",
"#types/express": "^4.17.9",
"#types/jsonwebtoken": "^8.5.0",
"cookie-session": "^1.4.0",
"express": "^4.17.1",
"express-validator": "^6.6.1",
"jsonwebtoken": "^8.5.1"
}
}
Anybody with experience in publishing packages on npm where TypeScript is involved? I am unclear as to why this package is not being found by my auth service when it is successfully installed inside that service.
Did I mess up in the way I am exporting inside my common/src/index.ts file?
export * from './errors/bad-request-error';
export * from './errors/custom-errors';
export * from './errors/database-connection-error';
export * from './errors/not-authorized-error';
export * from './errors/not-found-error';
export * from './errors/request-validation-error';
export * from './middlewares/current-user';
export * from './middlewares/error-handler';
export * from './middlewares/require-auth';
export * from './middlewares/validate-request';
Does it all have to be inside a module.exports instead?
So after reviewing a few blogs on Medium on how this is done, I noticed a couple of things.
Inside my tsconfig.js, this was missing:
/* Advanced Options /
"forceConsistentCasingInFileNames": true / Disallow inconsistencies */
So I manually added it in, secondly, I noticed something I meant to remove earlier but forgot. So instead of this:
{
"name": "#dc_microurb/common",
"version": "1.0.5",
"description": "",
"main": "./build/index.js",
"types": "./build/index.d.ts",
"files": [
"./build/**/*"
],
I needed to have it like this:
{
"name": "#dc_microurb/common",
"version": "1.0.6",
"description": "",
"main": "./build/index.js",
"types": "./build/index.d.ts",
"files": [
"build/**/*"
],
After making those couple of corrections, now my package is available to my auth service.
Related
I'm working on a node project using typescript, oclif and d3.js, among other things. Typescript was configured by npx when creating the project with oclif so I didn't control all aspects of it (especially regarding TS, and I'm not an expert. TS is great, but configuration wise, meh).
Anyway, everything was working fine, but I recently added d3 as a dependency and tried to build a document, and I get this error when running it:
(node:22554) [ERR_REQUIRE_ESM] Error Plugin: dbacl [ERR_REQUIRE_ESM]: require() of ES Module /dbacl/node_modules/d3/src/index.js from /dbacl/src/tree/graph-tree.ts not supported.
Instead change the require of index.js in /Users/nico/Furo/Dev/dbacl/src/tree/graph-tree.ts to a dynamic import() which is available in all CommonJS modules.
In the file where I'm using d3 I import it as per documentation:
import * as d3 from 'd3'
I suspect it might be a problem after compiling, so here is tsconfig.json. I didn't change anything since generation by npx.
{
"compilerOptions": {
"declaration": true,
"importHelpers": true,
"module": "commonjs",
"outDir": "dist",
"rootDir": "src",
"strict": true,
"target": "es2019",
},
"include": [
"src/**/*"
]
}
And in case it's more relevant, here is my package.json file as well (didn't change anything either):
{
"name": "dbacl",
"version": "0.0.0",
"description": "",
"author": "",
"bin": {
"dbacl": "./bin/run"
},
"license": "MIT",
"main": "dist/index.js",
"repository": "*****/dbacl",
"files": [
"/bin",
"/dist",
"/npm-shrinkwrap.json",
"/oclif.manifest.json"
],
"dependencies": {
"#oclif/core": "^1",
"#oclif/plugin-help": "^5",
"#oclif/plugin-plugins": "^2.0.1",
"#types/d3": "^7.4.0",
"#types/jsdom": "^16.2.14",
"d3": "^7.6.1",
"directory-tree": "^3.3.0",
"jsdom": "^20.0.0",
"lodash": "^4.17.21"
},
"devDependencies": {
"#oclif/test": "^2",
"#types/chai": "^4",
"#types/mocha": "^9.0.0",
"#types/node": "^16.9.4",
"chai": "^4",
"eslint": "^7.32.0",
"eslint-config-oclif": "^4",
"eslint-config-oclif-typescript": "^1.0.2",
"globby": "^11",
"mocha": "^9",
"oclif": "^3",
"shx": "^0.3.3",
"ts-node": "^10.2.1",
"tslib": "^2.3.1",
"typescript": "^4.4.3"
},
"oclif": {
"bin": "dbacl",
"dirname": "dbacl",
"commands": "./dist/commands",
"plugins": [
"#oclif/plugin-help",
"#oclif/plugin-plugins"
],
"topicSeparator": " ",
"topics": {
"hello": {
"description": "Say hello to the world and others"
}
}
},
"scripts": {
"build": "shx rm -rf dist && tsc -b",
"lint": "eslint . --ext .ts --config .eslintrc",
"postpack": "shx rm -f oclif.manifest.json",
"posttest": "yarn lint",
"prepack": "yarn build && oclif manifest && oclif readme",
"test": "mocha --forbid-only \"test/**/*.test.ts\"",
"version": "oclif readme && git add README.md"
},
"engines": {
"node": ">=12.0.0"
},
"keywords": [
"oclif"
],
"types": "dist/index.d.ts"
}
I find this problem quite confusing because everywhere I've been searching about this problem, it seems I'm doing the right thing. I assume the problem might be between my screen and my chair, but really I don't get it. Also, should I use the dynamic import like this?
const d3 = await import('d3')
I tried, it didn't work. I made the function that generates the document async and added that line at the start but nope. Anyway, if I believe the error, that would be the way to go but I didn't see this solution anywhere when looking for a solution to my problem. What do you guys think?
Thanks
So thanks to the input from a colleague and this article, the problem is that d3 now supports ESM only. So when the compiler turns the import into
// index.ts
import * as d3 from 'd3'
// compiled index.js
const d3 = require('d3')
it just doesn't work. I was using d3 version 7, and a quick fix to it was to downgrade to version 6.7.0, when it did support commonJS.
Now, I have to move on with this project, but I'll keep looking into it and into how I can use a recent version of d3 in my project. If I do, I'll edit that answer!
Cheers
I'm on a Win 8.1 x64 machine. When I try to run the generated Windows binaries, I get a Windows error message.
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.
What I've tried:
I've checked permissions, my UAC account already had full control.
I switched from using electron-forge make to electron-packager [folder] [projectTitle] --platform=win32 --arch=x64 (same error)
I updated npm, electron, electron-packager, electron-forge, and at one point had to install locally a series of packages and juggle some things from dep to devdep
In particular, I had to move electron dependency to the devdeps section in order to satisfy electron-forge
Copied the .exe to a different folder e.g. e:\ and tried running it from there (same error)
Running as Administrator (same error)
Changed electronPackagerConfig.packageManager to false per the recommended workaround for this recent known issue about pruning failing (not related to this problem, but it's a factor in play)
Opened both .exe's in 7zip and noticed that the one generated by electron-forge didn't have much in it. This may be nothing or it may correlate with the console output for that command, below.
My Goal:
This is my first electron app (I come from a web background). I'm doing this build as a sanity check before I start significantly integrating my app with electron's API.
Output of commands
electron-forge make
$ electron-forge make
We need to package your application before we can make it
[BABEL] Note: The code generator has deoptimised the styling of "E:/cygwin64/tmp/electron-packager/win32-x64/fictionDB-win32-x64/resources/app/.tmp/public/js/ckeditor/ckeditor.js" as it exceeds the max of "500KB".
[BABEL] Note: The code generator has deoptimised the styling of "E:/cygwin64/tmp/electron-packager/win32-x64/fictionDB-win32-x64/resources/app/.tmp/public/js/jquery-ui/jquery-ui.js" as it exceeds the max of "500KB".
Making for the following targets:
$
Notice how it seems to just cut off there? I wouldn't know but I'm guessing that's odd.
electron-packager . fictionDB --platform=win32 --arch=x64
$ electron-packager . fictionDB --platform=win32 --arch=x64
Downloading tmp-50796-1-SHASUMS256.txt-7.1.7
[============================================>] 100.0% of 5.56 kB (5.56 kB/s)
Packaging app for platform win32 x64 using electron v7.1.7
Wrote new app to E:\xxx\Documents\src\js_src\Projects\testbed6\fictionDB-win32-x64
$
package.json
{
"name": "fictionDB",
"private": false,
"version": "0.0.0",
"description": "A way for fiction writers to plan & organize",
"keywords": [
"organize",
"database",
"fiction",
"novel",
"stories",
"characters",
"events",
"locations",
"settings"
],
"dependencies": {
"#sailshq/connect-redis": "^3.2.1",
"#sailshq/lodash": "^3.10.3",
"#sailshq/socket.io-redis": "^5.2.0",
"acorn": "^7.1.0",
"ckeditor": "^4.12.1",
"connect-redis": "^4.0.3",
"electron-compile": "^6.4.4",
"electron-squirrel-startup": "^1.0.0",
"grunt": "^1.0.4",
"jquery": "^3.4.1",
"jquery-ui-dist": "^1.12.1",
"lodash": "^4.17.15",
"request": "^2.88.0",
"sails": "^1.2.3",
"sails-hook-grunt": "^4.0.1",
"sails-hook-orm": "^2.1.1",
"sails-hook-sockets": "^2.0.0",
"socket.io-redis": "^5.2.0"
},
"devDependencies": {
"babel-plugin-transform-async-to-generator": "^6.24.1",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"electron": "^7.1.7",
"electron-forge": "^5.2.4",
"electron-prebuilt-compile": "4.0.0",
"eslint": "5.16.0"
},
"scripts": {
"start": "electron-forge start",
"test": "npm run lint && npm run custom-tests && echo 'Done.'",
"lint": "./node_modules/eslint/bin/eslint.js . --max-warnings=0 --report-unused-disable-directives && echo '✔ Your .js files look good.'",
"custom-tests": "echo \"(No other custom tests yet.)\" && echo",
"package": "electron-forge package",
"make": "electron-forge make"
},
"main": "app/launch.js",
"repository": {
"type": "git",
"url": "git://github.com/NathanHawks/FictionDB.git"
},
"author": "Nathan Hawks",
"license": "MIT",
"engines": {
"node": "^8.9"
},
"config": {
"forge": {
"make_targets": {
"win32": [
"squirrel"
],
"darwin": [
"zip"
],
"linux": [
"deb",
"rpm"
]
},
"electronPackagerConfig": {
"packageManager": false
},
"electronWinstallerConfig": {
"name": "fictionDB"
},
"electronInstallerDebian": {},
"electronInstallerRedhat": {},
"github_repository": {
"owner": "",
"name": ""
},
"windowsStoreConfig": {
"packageName": "",
"name": "fictionDB"
}
}
}
}
I forgot to turn off antivirus shields. That fixed it. (For the permanent solution, I then added a security exception in my antivirus app's settings.)
As a note of interest, the version made by electron-forge didn't work:
However, the one made by electron-packager alone, worked fine.
I have a css build task that merges resources from bower dependencies and my own css.
The build task is part of project that uses git source control. The project has been running correctly for well over a year.
Up until yesterday, everything was working correctly on my windows laptop, when I reinstalled my npm dependencies that run the build task.
Below is a simplified example
gulpfile.js
var gulp = require('gulp'),
$ = require('gulp-load-plugins')();
gulp.task('default', function () {
return $.merge (
gulp.src('./bower.json')
.pipe($.mainBowerFiles('**/*.css', {
includeDev: 'exclusive',
group: 'css'
})
),
gulp.src(['./source/css/styles.css'])
)
.pipe($.plumber())
.pipe($.concat('stylesheet.css'))
.pipe(gulp.dest('./build/css'))
});
package.json
{
"name": "merge",
"version": "1.0.0",
"description": "",
"main": "gulpfile.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"devDependencies": {
"gulp": "^3.9.1",
"gulp-concat": "^2.6.1",
"gulp-load-plugins": "^1.5.0",
"gulp-main-bower-files": "^1.6.2",
"gulp-merge": "^0.1.1",
"gulp-plumber": "^1.1.0",
}
}
And bower.json
{
"name": "merge",
"description": "",
"main": "gulpfile.js",
"authors": [
""
],
"license": "ISC",
"homepage": "",
"private": true,
"ignore": [
"**/.*",
"node_modules",
"bower_components",
"test",
"tests"
],
"devDependencies": {
"normalize-css": "^7.0.0",
"reset-css": "^2.2.1"
},
"group": {
"css": [
"reset-css",
"normalize-css"
]
}
}
Prior to yesterday the task would merge both sources declared in $.merge(...). Since yesterdays' npm install I am finding that the merge will only output the result for the first declared source.
After some testing I have found that if I reverse the order of the merge sources than both sources are merged to the set output destination.
var gulp = require('gulp'),
$ = require('gulp-load-plugins')();
// the order of the sources has been reversed
gulp.task('default', function () {
return $.merge (
gulp.src(['./source/css/styles.css']),
gulp.src('./bower.json')
.pipe($.mainBowerFiles('**/*.css', {
includeDev: 'exclusive',
group: 'css'
})
)
)
.pipe($.plumber())
.pipe($.concat('stylesheet.css'))
.pipe(gulp.dest('./build/css'))
});
The problem with this solution is that that output content reversed, which may cause issues with style inheritance etc. This change to a successful output makes me think there may be an issue with how and where .pipe($.mainBowerFiles(...) is declared.
I've also tried replacing installed modules for gulp-merge and gulp-main-bower-files respectively with merge2 and main-bower-files.
Using either one or both solved the problem, however this isn't an ideal workaround as it means an update to the gulp task and installed modules.
This sudden failure to output tasks merge css ( or js ) in my project has real issues for any historic commit or branch in the project.
Is there away I can diagnose the failure of the original $.merge(...), or a way that I can retroactively replace gulp-merge with merge2 across all commits my git project and any branches?
I try to use Jest with bablejs and ES2017 in my project, according to the Jest Getting Started page and also Bablejs config for ES2017 this is my .babelrc file :
{
"presets": ["es2017"],
"env": {
"test": {
"presets": ["es2017"]
}
}
}
And my package.json is:
{
"name": "",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "jest"
},
"repository": {
"type": "git",
"url": ""
},
"author": "",
"license": "ISC",
"bugs": {
"url": ""
},
"homepage": "",
"devDependencies": {
"babel-cli": "^6.26.0",
"babel-core": "^6.26.0",
"babel-jest": "^21.2.0",
"babel-polyfill": "^6.26.0",
"babel-preset-es2017": "^6.24.1",
"jest": "^21.2.1"
}
}
When I type npm test to run all my test with jest i get these error :
){import StateList from './StateList';
^^^^^^
SyntaxError: Unexpected token import
It means it doesn't know import.
babel-preset-es2017 does not transform import statements, because it only includes the plugins: syntax-trailing-function-commas and
transform-async-to-generator.
When installing babel-preset-es2017 you also get a warning that it has been deprecated in favour of babel-preset-env, which contains everything that the es201x presets contained and more.
warning babel-preset-es2017#6.24.1: 🙌 Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!
As shown in the Migration guide from es2015 to env, it is a drop-in replacement.
npm install --save-dev babel-preset-env
And change your .babelrc to:
{
"presets": ["env"]
}
Do not confuse babel-preset-env with Babel's env option, which I have removed from your current config, since you are using the exact same presets for the test environment as for any other, so it doesn't have any effect.
You can configure babel-preset-env to only transform features that are not supported by the platform you target, for example { "targets": { "node": "current" } } will only transform features that aren't supported by the Node version you are running. If no targets are specified, it will transform everything. For details see the Env preset documentation.
Note: With the upcoming version 7 of Babel, the official packages will be published under the namespace #babel, which means that babel-preset-env will be #babel/preset-env.
I'm working on two Node packages at once, let's call them Library and Consumer. Library is responsible for rendering a bunch of stuff in the browser. All Consumer does is import Library from 'library' and call Library(someConfigHere) -- it's basically just a test to make sure Library is doing what I expect in the browser.
I've npm linked Library into Consumer and am trying to run Browserify on Consumer, but I get this error: ParseError: 'import' and 'export' may appear only with 'sourceType: module'. Library does indeed contain an ES6 export statement, so I'm guessing that Browserify is only running against Consumer and not Library.
So my question is: is there any way to force Browserify to transform dependencies as well?
This is my package.json:
{
"name": "consumer",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"start": "budo index.js --port $PORT",
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"devDependencies": {
"babel-preset-es2015": "^6.13.2",
"babel-preset-react": "^6.11.1",
"babelify": "^7.3.0",
"browserify-shim": "^3.8.12"
},
"browserify": {
"transform": [
"babelify"
]
},
"babel": {
"presets": [
"es2015",
"react"
]
}
}
This is Consumer's index.js:
import Library from 'library' // <= this is what isn't getting babelified
console.log(Library);
This is Library's index.js:
export default (config) => {
console.log('Testing testing')
}
Browserify transforms can be configured to be global, which means they will be applied to files within node_modules, too.
The configuration is per-transform. With babelify, you'd configure it like this:
browserify().transform("babelify", {
global: true
})
Or, if you are using the command line, like this:
browserify ... -t [ babelify --global ] ...
Or, to configure it in the package.json, it should be something like this (note the added square brackets):
"browserify": {
"transform": [
["babelify", { "global": true }]
]
}
Babelify also implements an ignore option, so it would be possible to configure it to transform only the files within node_modules that you want it to. There is more information here.
Another solution would be to include a similar browserify/babelify configuration in your library module's package.json. When processing dependencies, Browserify will check said dependency's pacakge.json files for transforms and will apply any that are configured.