I begin with Typescript and i try to create a new module but i have some problems.
I want to import a js file into my index.ts, so i know that I have to create a d.ts file in order to create and explain the function for typescript. Into my index.ts i put this :
import Toto from "./toto";
And this is my d.ts file :
declare module 'Toto' {
function myfunction(callback : Function);
export default myfunction;
}
But into my d.ts file i have this error :
TS1128 : Declaration or Statement expected
I don't understand why because my test is very easy.
I use webpack to build the code, this is my webpack.config.js
module.exports = {
entry: "./index.ts",
output: {
path: "bundle/",
filename: "bundle.js"
},
resolve: {
extensions : [".ts", ".tsx", ".js"]
},
module: {
loaders: [
{ test: /\.tsx?$/, loader: "ts-loader" }
]
}
};
And my tsconfig.json
{
"compilerOptions": {
"target" : "es5"
}
}
If you have any ideas :)
Regards
If you want to load .js files directly just set the "allowJS" flag in the compiler options. TS will then try to use type inference based on the JS.
TS Compiler options
So in you case just add the allowJS flag to the compiler options and skip the d.ts file.
This set-up works for me
//toto.js
function myfunction(callback) {
callback("42")
}
exports.default=myfunction
//toto.d.ts
export default function myfunction(callback : Function);
//main.ts
import myfunc from './toto'
myfunc((res) => console.log(res) )
//tsconfig.json
{
"compilerOptions": {
"target" : "es5"
}
}
Running node main.js correctly logs 42
Alternatively using allowJs
from the set-up above, remove the toto.d.ts definition file
add "allowJs":true in tsconfig compilerOptions
=> The first solution requires the crafting of a definition file, but you benefit from typings when using myfunc in main.ts.
Finally i found my problem, my EDI (phpStorm) was too old and it compile the code in Typescript 1.4 whereas i was in Typescript 2.2.1...
Thanks for your feedback i don't know that i can use this option allowJs but for me it's not recommended because i want to document my code with typedoc and i need to create this d.ts file in order to do that.
Related
TL;DR
How can you tell SWC to compile CSS files imported in React components?
How can you tell SWC to compile absolute imports in tests and in React components?
Here is a minimal reproducible example.
Context
We're migrating from Babel to SWC. (I asked a question a little while ago. I'm improving on that question's answer.)
We're migrated the command from:
"test": "NODE_ENV=test riteway -r #babel/register 'src/**/*.test.js' | tap-nirvana",
to
"test": "SWC_NODE_PROJECT=./jsconfig.json riteway -r #swc-node/register src/**/*.test.js | tap-nirvana",
where the jsconfig.json looks like this:
{
"compilerOptions": {
"allowJs": true,
"baseUrl": "./src",
"jsx": "react-jsx"
}
}
If we write try to compile a test for a self-contained component (no absolute imports, no CSS) it works:
import { describe } from 'riteway';
import render from 'riteway/render-component';
function HomePageComponent({ user: { email } }) {
return <p>{email}</p>;
}
describe('home page component', async assert => {
const user = { email: 'foo' };
const $ = render(<HomePageComponent user={user} />);
assert({
given: 'a user',
should: 'render its email',
actual: $('p').text(),
expected: user.email,
});
});
The test compiles fine.
With Babel we had a .babelrc like this:
{
"env": {
"test": {
"plugins": [
[
"module-resolver",
{
"root": [
"."
],
"alias": {
"components": "./src/components",
"config": "./src/config",
"features": "./src/features",
"hocs": "./src/hocs",
"hooks": "./src/hooks",
"pages": "./src/pages",
"redux": "./src/redux",
"styles": "./src/styles",
"tests": "./src/tests",
"utils": "./src/utils"
}
}
]
]
}
},
"presets": [
[
"next/babel",
{
"ramda": {}
}
]
],
"plugins": [
["styled-components", { "ssr": true }]
]
}
Where the styles where taken care of by styled-components and the absolute imports where defined via the module-resolver plugin. (We switched away from styled-components to CSS modules, which is why we import from .module.css CSS files. Anyways ...)
If we write the test how we wanted to write it with their actual imports like this:
import { describe } from 'riteway';
import render from 'riteway/render-component';
import { createPopulatedUserProfile } from 'user-profile/user-profile-factories';
import HomePageComponent from './home-page-component';
describe('home page component', async assert => {
const user = createPopulatedUserProfile();
const $ = render(<HomePageComponent user={user} />);
assert({
given: 'a user',
should: 'render its email',
actual: $('p').text(),
expected: user.email,
});
});
It fails with:
$ SWC_NODE_PROJECT=./jsconfig.json riteway -r #swc-node/register src/features/home/home-page-component.test.js | tap-nirvana
/Users/janhesters/dev/my-project/src/features/home/home.module.css:1
(function (exports, require, module, __filename, __dirname) { .container {
^
SyntaxError: Unexpected token '.'
when we leave in the CSS import in home-page-component.js, or with:
$ SWC_NODE_PROJECT=./jsconfig.json riteway -r #swc-node/register src/features/home/home-page-component.test.js | tap-nirvana
node:internal/modules/cjs/loader:936
throw err;
^
Error: Cannot find module 'user-profile/user-profile-factories'
Require stack:
- /Users/janhesters/dev/my-project/src/features/home/home-page-component.test.js
- /Users/janhesters/dev/my-project/node_modules/riteway/bin/riteway
respectively, when we get rid of the CSS import.
How can we help SWC understand CSS (or mock CSS modules) and how can we help it understand absolute imports?
We already set the baseUrl in jsconfig.json ...
About absolute path
You already add baseUrl in the jsconfig.json file but didn't add the paths, you should modify your config file like mine:
{
"compilerOptions": {
"baseUrl": "./src",
"paths": {
"#screens": ["./screens"],
"#shared": ["./shared"],
"#shared/*": ["./shared/*"]
},
The paths are the alias of module-resolver, and I guess your root shouldn't be ".", it should be exactly like your jsconfig.json file, I mean the baseUrl value.
"plugins": [
[
"module-resolver",
{
"root": ["./src"],
"extensions": [".ts", ".tsx", ".js", ".jsx", ".json"],
"alias": {
"#screens": "./src/screens",
"#shared": "./src/shared"
}
}
]
],
If you have Webpack, you should have alias config in your resolve key off Webpack config object, like mine:
const resolve = {
extensions: ['.js', '.jsx', '.ts', '.tsx', '.json'],
alias: {
'#screens': path.join(__dirname, 'src/screens/'),
'#shared': path.join(__dirname, 'src/shared/'),
},
modules: ['src', 'node_modules'],
descriptionFiles: ['package.json'],
};
About CSS
Actually, you are using CSS file as CSS-Modules not like recommended NexJS doc, in docs developer should import CSS like import './styles.css' and then use it as string in JSX like <div className="main"
But
You are importing it like a module (CSS-Module):
// you did it
import styles from './styles.css';
<div className={styles.main}
As you know it is built-in support by this doc, it is supported by NextJS, but SWC cannot understand it. I put in hours to find a way for it, but it seems SWC doesn't support CSS-Module yet. you should create your own plugin for SWC to support CSS-Module.
How can we help SWC understand CSS (or mock CSS modules)? - SWC doesn't understand css natively, and neither did Babel. As you noted, when you were using Babel, the plugin styled-components took care of this. You'll need to do the same with SWC. I can't find an existing SWC plugin that does this, but you can roll your own. Obviously this is a pain, but such is the cost of using new tooling.
How can we help SWC understand absolute imports? - The .swrc options for baseUrl and paths should do what you want, but that, too, seems to have some issues.
You may have better luck creating issues directly in the #swc-node GitHub repo, but given the comments there it feels like you might be SOL for a while. Might be faster/easier to rewrite your tests using one of the libraries that Next supports out of the box.
I was able to solve all issues without writing any plugins. I pushed the solution to my example repo from the question.
Firstly, use the official SWC project's register. This means, you have to compile your tests like this:
"test": "riteway -r #swc/register 'src/**/*.test.js' | tap-nirvana",
You can install it by running:
yarn add --dev #swc/core #swc/register
We need this version of register, because it takes into account an .swcrc file, which the other one did not.
Secondly, you need both "path" and "baseUrl" to fix the absolute imports because for some reason SWC doesn't infer all paths with only a "baseUrl" provided. And you need to adapt your .swcrc to handle React.
{
"jsc": {
"baseUrl": "./src",
"paths": {
"*.css": ["utils/identity-object-proxy.js"],
"utils/*": ["utils/*"]
},
"parser": {
"jsx": true,
"syntax": "ecmascript"
},
"transform": {
"react": {
"runtime": "automatic"
}
}
},
"module": {
"type": "commonjs"
}
}
Thirdly, to solve .css you need to remap all imports to .css files to an identity object proxy, which you can see in the .swcrc example above. An identity object proxy is an object that, when you reference any property, returns the stringified key that you're trying to reference. You can create one yourself like this:
const identityObjectProxy = new Proxy(
{},
{
get: function getter(target, key) {
if (key === '__esModule') {
return false;
}
return key;
},
},
);
export default identityObjectProxy;
For the .css remap to go into effect you need to make all your imports to .css files absolute imports. (import styles from './styles.module.css won't work!)
I am trying to make a library/package from my component.
Tech-stack is: React, Typescript... and a bunch of other dependencies.
I am using Rollup and when I try to build the package I get the following error:
[!] Error: 'DisplayHint' is not exported by
../node_modules/#bestowinc/enroll-sdk-core/build/lib/question-common.js,
imported by ../src/utils/answerTypeConversions.ts
https://rollupjs.org/guide/en/#error-name-is-not-exported-by-module
Rollup:
import babel from 'rollup-plugin-babel';
import resolve from '#rollup/plugin-node-resolve';
import external from 'rollup-plugin-peer-deps-external';
import { terser } from 'rollup-plugin-terser';
import postcss from 'rollup-plugin-postcss';
import reactSvg from 'rollup-plugin-react-svg';
import typescript from 'rollup-plugin-typescript2';
import svg from 'rollup-plugin-svg';
import commonjs from '#rollup/plugin-commonjs';
import json from '#rollup/plugin-json';
import replace from '#rollup/plugin-replace';
import urlResolve from 'rollup-plugin-url-resolve';
export default [
{
input: './src/index.ts',
output: [
{
file: './dist/index.js',
format: 'cjs',
sourcemap: true,
},
{
file: './dist/index.es.ts',
format: 'es',
exports: 'named',
sourcemap: true,
},
],
plugins: [
typescript({
tsconfig: './tsconfig.build.json',
verbosity: 3,
clean: true,
check: true,
}),
babel({
exclude: ['/node_modules'],
presets: [
'#babel/preset-react',
'#babel/preset-flow',
'#babel/preset-env',
],
extensions: ['.ts', '.tsx'],
}),
commonjs({
include: './node_modules',
dynamicRequireTargets: [
// include using a glob pattern (either a string or an array of strings)
'/node_modules/#bestowinc/enroll-sdk-core/build/lib/question-common.js',
'./node_modules/#bestowinc/enroll-sdk-core/build/lib/question-common.js',
],
}),
resolve({
browser: true,
preferBuiltins: true,
mainFields: ['browser'],
}),
urlResolve(),
postcss({
plugins: [],
minimize: true,
}),
external(),
terser(),
reactSvg({
jsx: false,
include: ['custom.d.ts'],
exclude: null,
}),
svg(),
replace({
include: ['../src/icons/**'],
preventAssignment: true,
// Replace ReactComponent to allow resolution of SVG files under Rollup
ReactComponent: 'default',
}),
json(),
],
},
];
DisplayHint:
/**
* An indication of how clients should display a question.
*
* This is inferred from the answer_format and answer_display api properties.
* Those properties should not be used directly, and clients should rely instead
* solely on DisplayHint.
*/
export declare const DisplayHint: {
readonly ButtonGroup: "DisplayHint::ButtonGroup";
readonly Checkbox: "DisplayHint::Checkbox";
};
export declare type DisplayHint = typeof DisplayHint[keyof typeof DisplayHint];
Looks like DisplayHint is a TS type/interface, not an exported JS value.
Rollup per se is a bundler not a TS language analyzer. It cannot tell if a named export is a concrete JS value or merely a non-existing TS type, thus the reported error.
Rollup plugin order matters. To resolve this specific problem, just lift the typescript plugin up in order, at least before babel. TS plugin, if put to work first, will correctly erase TS type from JS code output.
Update
I know another trick, but it’s a workaround-ish one. The trick is to use import type syntax to explicitly mark DisplayHint as a TS type.
import type { DisplayHint } from "#bestowinc/enroll-sdk-core"
import { otherNonTypeStuff } from "#bestowinc/enroll-sdk-core"
This trick is not satisfying because it requires you to explicitly mark everywhere you need a TS type, and you have to separate concrete JS exports from TS type ones, like shown above. This is fine if it’s a one-off thing but if you have a large codebase it’s very tedious.
I have to add, it’s unexpected to me that original solution doesn’t work. My guess is that this module #bestowinc/enroll-sdk-core is somehow quirky. (Why you include them as dynamic import target in the config anyway?)
It’s a JS module with .d.ts annotation, that I can tell, but looks like it’s a private module, I cannot see the code thus cannot dive deeper. My guess is that .d.ts declaration is broken, it doesn’t match up to the real export of JS code.
Anyway, I hope this trick resolve your problem. If you need me to look closer, I’ll have to ask you to setup a minimal reproducible example. With current info there’s not much I can do.
I've had similar issue just happening with linked library (with typescript plugin in place), in my case solution was to add the linked library to config 'external' property. But node_modules should be treated as external anyway so not sure if this will apply
I found a plugin rollup-plugin-multi-input which fixes the problem of not being able to specifiy a glob to the test rollup config. For the unt tests, the entry point is not a single entity from which an import graph can be derived. It is just a collection of source files containing tests, which doesnt fit input requirement of rollup.
However, my attempt at trying to use it was fruitless:
rollup-config.tests.mjs:
import multi from 'rollup-plugin-multi-input';
const testConfig = {
input: ['test/**/*.spec.ts'],
external: ["chai", "mocha", "dirty-chai"],
output: {
format: "es",
file: `dist/${name}-bundle.test.js`,
plugins: [],
sourcemap: true
},
plugins: [
multi(),
resolve(),
commonjs(),
typescript({
tsconfig: "./tsconfig.test.json"
})
],
}
just resulted in this error:
[!] TypeError: multi is not a function
TypeError: multi is not a function
Looking at the exported code from the plugin, I can see that the default export is a function:
var _default = function(param) {
}
exports.default = _default;
So I don't know why this doesnt work.
I since discovered that there is another plugin that does a similar thing: #rollup/plugin-multi-entry:
import entry from "rollup-plugin-multi-entry";
plugins: [
entry(),
resolve(),
commonjs(),
typescript({
tsconfig: "./tsconfig.test.json"
})
],
so configured and invoked in exactly the same way, but now it works in the way that I wanted it to; the test bundle is created and mocha indeed sees all the tests and executes them successfully.
So let's take a look at that export and see if there is a difference in what is exported:
Well the first thing to notice is that its dist folder contains a .mjs file and a .js file. Since we're importing from an ESM package ("type": "module" in package.json), I guess we're using the default export from the .mjs file:
function multiEntry() {
...
}
export default multiEntry;
With rollup-plugin-multi-input, I even tried using the createRequire from "module":
import { createRequire } from "module";
const require = createRequire(import.meta.url);
const multi = require('rollup-plugin-multi-input');
but that failed for the same reason.
So whats the problem here? Why does default import from rollup-plugin-multi-input not work?
I would like to use an alias in VUE.JS in a Laravel 5.8 project to import css and js I have in my module.
webpack.mix.js
mix.webpackConfig({
resolve: {
alias: {
'alias': path.resolve(
__dirname,
'~myModule/src'
)
}
}
});
In my VUE App.js I would like import the css folder and I wrote:
resources/js/app.js
// css files
import 'alias/lib/css'
// js files
import 'alias/lib/script'
But I'm wrong something becouse the alias is not resolved:
ERROR in ./resources/js/app.js
Module not found: Error: Can't resolve 'alias/lib/css' in...
Can you help me to fix the issue?
After so many attempts I got the issue. The code was good but I was missing to load the webpack.mix.js properly:
From Laravel Mix documentation:
The webpack.mix.js file is your entry point for all asset compilation. Think of it as a light configuration wrapper around Webpack. Mix tasks can be chained together to define exactly how your assets should be compiled.
But if you are using npm run watch it is not (re)loaded before to compile new changed assets. This means:
if you are in watch mode (npm run watch) exit and restart it to load new updated webpack.config.js if you changed it.
Finally it worked! And it resolve new alias properly!
Here the final config I used in webpack.config.js:
mix.webpackConfig({
resolve: {
alias: {
'aliasName': path.resolve(
__dirname,
'node_modules/MyModule/src/'
)
}
}
});
Another alternative is:
mix.webpackConfig({
resolve: {
modules: [
'node_modules'
],
alias: {
'aliasName' : 'MyModule/src/'
}
}
});
Then in my Vue component (or in vue app.js, just in case)
<template>
<myModule-component></myModule-component>
</template>
require('aliasName/lib/css'); // to load full css directory
require('aliasName/lib/script'); // to load full js directory
import MyModuleComponent from 'aliasName/widgets/MyModuleComponent.vue'
...
export default {
...
components: {
'myModule-component': MyModuleComponent
}
The setting
I am trying to load existing AMD modules with TypeScript.
To demonstrate my problem, here is an app.ts file that loads an AMD module named my_amd_module.js:
// app.ts
import * as amd_func from './my_amd_module';
function main(): void {
console.log(amd_func());
}
main();
The following TypeScript configuration is used:
// tsconfig.json
{
"compileOnSave": true,
"compilerOptions": {
"allowJs": true,
"outDir": "build",
"sourceMap": true,
"target": "es5"
},
"exclude": [
"node_modules",
"build"
]
}
And I am using Webpack to bundle the app.ts file in a package named app-bundle.js that can be run by a browser:
// webpack.config.js
'use strict';
const webpack = require('webpack');
const path = require('path');
module.exports = {
context: path.resolve(__dirname, 'src'),
entry: './app.ts',
output: {
path: path.resolve(__dirname, 'build'),
filename: 'app-bundle.js'
},
devtool: 'source-map',
resolve: {
extensions: ['', '.ts', '.js']
},
module: {
loaders: [
{test: /\.ts$/, loader: 'ts-loader'}
]
}
};
The working version
When the my_amd_module.js looks as following, everything is working fine. Notice that I am referencing 'module' as a dependency and bind the function foo to it’s exports property which is one possible flavor of using AMD.
// my_amd_module.js
define(['module'], function(module) {
function foo () {
return 'Hello from AMD!';
}
module.exports = foo;
});
The not working version
But when I am using the alternative syntax of defining an AMD module with a return value instead of assigning to exports
// my_amd_module.js
define(function() {
function foo () {
return 'Hello from AMD!';
}
return foo;
});
then the TypeScript compiler complains with the following message:
ERROR in ./app.ts
(1,27): error TS2306: File '/[...]/src/my_amd_module.js' is not a module.
But the app-bundle.js file is still generated and everything works in the browser.
The alternative syntax I am using in this case is, for example, described by RequireJS or in the AMD specification itself.
My question
Are AMD modules that define their exported value with a return value instead of assigning to exports not supported by TypeScript? Is this the reason why the compiler is complaining? And why is everything compiled, despite this complaint?
Are AMD modules that define their exported value with a return value instead of assigning to exports not supported by TypeScript
Yes. Apparently it is not detected as an external module and inferred to be global and hence not allowed to be required. Please raise an issue here : https://github.com/Microsoft/TypeScript/issues