Support of assert {type: "json"}

[pubmikeb]

Starting Node.js 17.1.x, the assert {type: "json"} suffix is mandatory to be able importing the JSON modules. ESLint 8.2.0 is not aware of this syntax and therefore marks it as an error:

ESLint: Parsing error: Unexpected token assert

The problem is that after this error is thrown, no further linting is performed, ESLint doesn't analyze any further line of code and bearing in mind that usually loading of JSON modules defined somewhere at the beginning of a file, ESLint doesn't scan the entire file.

Currently, the Import Assertions is on the stage 3 and I know that ESLint accepts new JS features starting the stage 4, but bearing in mind a fact that without a support of assert {type: "json"}, ESLint can't scan the entire file, it would be great to propose some workaround prior reaching the stage 4.

[nzakas]

We have the policy to wait until stage four because We don’t know which ECMA version it will end up in. Once import assertions have landed in an ECMAScript version, we can look at adding support in ESLint. In the meantime, you’ll need to use some thing like the Babel ESLint parser to get the support.

[jammi]

Are you done waiting? I'm encountering this linting code running on node v19.3.0

[RagnarLothbrok-Odin]

^ what jammi said, this warning is irritating

[ntatko]

Still an issue...

[qubyte]

Worth noting: that while JSON modules are now their own proposal at stage 3, the proposal which spawned it (import assertions) had issues, dropped back to stage 2, and then was changed to import attributes. That proposal replaces the keyword assert with with. I don't have an insight into the process, but the odds seem good that it will affect the JSON modules proposal.

It seems wise to be especially strict with this proposal.

[alexfernandez]

It's now 2023-08-16 and the import proposal seems to be back at stage 3. To be honest both options, with and assert, are horrible; but at this stage anything is better than nothing since it's already implemented in Node.js. Let's hope it's approved soon 🤞

[msurdi]

I know it is far from ideal and only works on a node environment, but this workaround worked for me in the meanwhile and I thought it might help others reading this in the future:

import { readFileSync } from "fs";
const packageJSON = JSON.parse(readFileSync("./package.json"));

[kenbankspeng]

Thank you @msurdi. It seems to me that relative paths in import statements are relative to the file in which they are written, but relative paths in the parameter to readFileSync is relative to where node is run. I suppose in the case of a server, node is likely run from the same path location so it doesn't matter, but using node spuriously via a command line for running scripts from various path locations, this is an issue. Maybe better to ensure relative paths are relative to the file like import.

Seems __dirname is not supported in Node ES Modules, so URL and import.meta.url does the job for me. Maybe this could be improved further with import mapping or parameterizing it into a utility function importJson.

import { readFileSync } from "fs";
const fileUrl = new URL("../../path/relative/to/this/file/myJson.json", import.meta.url);
const packageJSON = JSON.parse(readFileSync(fileUrl));

[qubyte]

This blocks, when ES modules need not since they're async. Top-level await is available in all supported versions of Node, so the following is better:

import { readFile } from 'node:fs/promises';
const fileUrl = new URL("<the relative path from this module>", import.meta.url);
const parsedPackageJSON = JSON.parse(await readFile(fileUrl, 'utf8'));

[leke-osez]

This blocks, when ES modules need not since they're async. Top-level await is available in all supported versions of Node, so the following is better:

import { readFile } from 'node:fs/promises';
const fileUrl = new URL("<the relative path from this module>", import.meta.url);
const parsedPackageJSON = JSON.parse(await readFile(fileUrl, 'utf8'));

[TriMoon]

@pubmikeb

#15305 (comment)
I know it is far from ideal and only works on a node environment, but this workaround worked for me in the meanwhile and I thought it might help others reading this in the future:

BIG thanks to @msurdi 💯 😍 !!!

I now use this as my rollup.config.mjs thanks to you:

import { copy } from '@guanghechen/rollup-plugin-copy'
import sourcemaps from 'rollup-plugin-sourcemaps'
import { terser } from 'rollup-plugin-terser'
/**
 * Work-around for eslint's failure for import-assert !
 * @todo Until eslint supports this, we need this work-around !
 * @see {@link https://github.com/eslint/eslint/discussions/15305#discussioncomment-2400923 solutions attribution}
 */
// import pkg from './package.json' assert {type: 'json'};
import { readFileSync } from 'fs'

function addCopyrights(minified){
	return [
		'/**'
		,(minified ? ' * minified version\n' : '')
			+ ' * @copyright	See the `/LICENSE.*` file for details.'
		,' * @license		CC-BY-NC-SA-4.0'
		,' */'
	].join('\n')
}

const
	buildDir = 'public'
	,sourcesDir = 'src'
	,_buildStamp = new Date().toISOString()
	/* eslint-disable comma-style */
	,/**
	 * Work-around for eslint's failure for import-assert !
	 * @todo Until eslint supports this, we need this work-around !
	 * @see {@link https://github.com/eslint/eslint/discussions/15305#discussioncomment-2400923 solutions attribution}
	 */
	pkg = JSON.parse(readFileSync('./package.json'))
	/* eslint-enable comma-style */

	,commonOutputOptions = {
		dir: buildDir
		,entryFileNames: '[name].mjs'
		,banner:
			addCopyrights(false)
			// Add _BUILDSTAMP_ here so it will be optimized also.
			+ `\nconst _BUILDSTAMP_ = "${pkg.version}@${_buildStamp}";`
		,preserveModules: false
		,preserveModulesRoot: sourcesDir
		,sourcemap: true
		,sourcemapExcludeSources: true
	}

	,terserOptions = {
		ecma: '2015'
		,format: {
			preamble: addCopyrights(true)
			// Don't preserve ANY comments.
			,comments: false
		}
		/**
		* Required for our logger to show meaningfull stacktraces !
		*/
		// eslint-disable-next-line camelcase
		,keep_fnames: true	// spell-checker: disable-line
		// eslint-disable-next-line camelcase
		,keep_classnames: true
		,module: true
		,compress: false
		// ,compress: {
		// 	passes: 2	// More as 2 has no effect atm...
		// }
	}

	,copyStaticFilesOptions = {
		verbose: true
		,targets: [
			// Unaltered
			{
				src: [
					'LICENSE.md'
					,'README.html'
					,`${sourcesDir}/*.{css,svg,png}`
				]
				,dest: buildDir
				// ,copyOnce: true
			}
			// Using non-minimized js
			,{
				src: `${sourcesDir}/*.html`
				,dest: buildDir
				,rename:	name => name + '.nonmin.html'
			}
			// Using minimized js
			,{
				src: `${sourcesDir}/*.html`
				,dest: buildDir
				// ,copyOnce: true
				,transform:	contents => contents
					.toString()
					.replace('app.mjs' ,'app.min.mjs')
			}
		]
	}

export default {
	input: [
		`${sourcesDir}/app.mjs`
		,`${sourcesDir}/ThreeD-app.mjs`
	]
	,output: [
		{
			...commonOutputOptions
		}
		,{
			...commonOutputOptions
			,entryFileNames: '[name].min.mjs'
			,plugins: [
				terser(terserOptions)
			]
		}
	]
	,plugins: [
		sourcemaps()
		,copy(copyStaticFilesOptions)
	]
	,watch: {
		clearScreen: false
	}
	// ,perf: true
}

Maybe that config can help some other readers in future also 😉

[zhyd1997]

Try this solution:

yarn add -D @babel/eslint-parser @babel/plugin-syntax-import-assertions

// .eslintrc.js
  parser: "@babel/eslint-parser",
  parserOptions: {
    requireConfigFile: false,
    babelOptions: {
      plugins: [
        '@babel/plugin-syntax-import-assertions'
      ],
    },
  },

It works for me.

[johnsonsamuel]

Thank you so much for this 🙏🏽.

[gugiserman]

works like a charm! thanks! 🚒

[pprasannan]

Thank you so much @zhyd1997 ❤️

[qa-leads-videoslots]

I did the following and while it worked well, all of my rules are no longer being triggered, any help with that?

[thescientist13]

Yeah, my plugins don't seem to be working after this (though the import attributes syntax now lints correctly), but its only a minor one so I can live with it for now.

[neilpa]

If you control the launching of the node process (e.g. a test suite) you can avoid the import assertion completely with a custom loader. You do get some annoying warnings though.

$ node --experimental-loader ./loader.js main.js             
(node:55385) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
{ foo: 'bar' }
(node:55385) ExperimentalWarning: Importing JSON modules is an experimental feature. This feature could change at any time

main.js

import data from './data.json'
console.log(data);

data.json

{
  "foo": "bar"
}

loader.js

import path from 'path';
import { promises as fs } from 'fs';
import urlModule from 'url';

export async function load(url, context, defaultLoad) {
  const filename = urlModule.fileURLToPath(url);
  const parts = path.parse(filename);
  if (parts.ext === ".json") {
    const source = await fs.readFile(filename);
    return { source, format: 'json', shortCircuit: true };
  }

  return await defaultLoad(url, context);
}

[joostdecock]

I use this low-tech solution where I bundle all JSON imports in 1 file, and then re-export them as named exports.
Then, I just put this 1 file (that I call json-loader.mjs in .eslintignore and gone are the errors.

/*
 * Eslint does not support import assertions because they only
 * support stage-4 language features.
 *
 * It's annoying and can't be disabled. So instead this file
 * will import all JSON and you can then import it from here.
 *
 * This way, we just ignore this file in eslint and voila.
 */
import dockerAllContainersExample from './docker-all-containers.json' with { type: 'json' }
import dockerRunningContainersExample from './docker-running-containers.json' with { type: 'json' }
import dockerDfExample from './docker-df.json' with { type: 'json' }
import dockerInfoExample from './docker-info.json' with { type: 'json' }
import dockerImagesExample from './docker-images.json' with { type: 'json' }
import dockerNetworksExample from './docker-networks.json' with { type: 'json' }


export {
  dockerAllContainersExample,
  dockerRunningContainersExample,
  dockerDfExample,
  dockerInfoExample,
  dockerImagesExample,
  dockerNetworksExample,
}

[mryechkin]

Clever! I'll have to remember this.

[phish108]

A little side note: assert has dropped from the spec. The correct syntax uses now with

import foobarExample from './foobar.json' with { type: 'json' }

see: https://nodejs.org/api/esm.html#import-specifiers

[joostdecock]

Ah yes, good point. I've updated the example accordingly, for the benefit of future visitors.
Thanks for pointing it out 🙏