Microbundle: Typescript build "breaking" by not bringing in types.d.ts

Created on 14 Mar 2019  路  4Comments  路  Source: developit/microbundle

I have the following project, it's not building my types into the dist folder and so the output is broken. It's useable without the consumer using typescript however, which is why I included the quotes 馃槄

src/index.tsx
import { ITheme } from './types'
const Theme: ITheme = {
    colours: ..
    tones: ...
}
export default Theme
src/types.d.ts
export interface ITheme {
    colours: IColours
    tones: ITones
}
package.json
{
  "name": "@my/theme",
  "main": "dist/index.js",
  "source": "src/index.tsx",
  "typings": "src/types.d.ts",
  "scripts": {
    "build": "rimraf dist/ && microbundle",
    "test": "react-scripts test"
  },
  "private": true,
  "devDependencies": {
    "@types/jest": "^24.0.11",
    "microbundle": "^0.11.0",
    "rimraf": "^2.6.3",
    "polished": "^3.0.3"
  },
  "peerDependencies": {
    "polished": "^3.0.3"
  }
}

Running microbundle results in an error inside 'index.d.ts', since 'dist/types.d.ts' does not exist.

dist/index.d.ts
import { ITheme } from './types'; // this line errors in my IDE since './types/ does not exist
declare const theme: ITheme;
export default theme;

I solved it by including the follow command:

"build": "rimraf dist/ && microbundle && cp src/types.d.ts dist/types.d.ts",

But now I have to do:

import Theme from '@my/theme'
import { ITheme } from '@my/theme/dist/types'

Which is a bit ugly, it would be nice just to do

import Theme, { ITheme } from '@my/theme'

Is this possible?

Most helpful comment

As @ForsakenHarmony has said, generally types should be defined in a .ts file.

.d.ts files are only used at build time, and don't produce any file. I guess this is why rollup doesn't include it in the dist.

.d.ts files are used to describe files that aren't TypeScript, or have a DefinitlyTyped entries. And as such the way you think about them are:

_I have a node_module called ./types, which is a .js module. But I would like TypeScript to give my type hints, and check my code at compile time, so im going to create a types.d.ts file to define this module being imported. But at runtime (and runtime being JavaScript), still treat that ./types as a node_module and import it accordingly._

__TL;DR:__ Rename your types.d.ts -> types.ts and you'll be good to go, and you'd more spec compliant to its meaning.

All 4 comments

Why are you using typings internally?

Would probably work if you just had types.ts

Do you mind clarifying your first question? I am still learning typescript so it's not the clearest question for me at the moment. I can think of 3 ways to interept it:

Why am I using them internally like on the last line? If so then it's because I am using emotion 10's css prop, which is not a standard jsx prop and I couldn't figure out how to make it typed by TS.

So I have to do something like:

<div css={(theme: ITheme) => ({ background: theme.colours.primary.neutral })}>..</div>

If you mean why am I using the types inside src/index.tsx then it's because I didn't know how else to handle it. I was not able to configure vscode to say that this theme object inside src/index.tsx is the interface ITheme from types.d.ts. I am still learning Typescript so perhaps this is a gap in my knowledge.

If you mean I should have my types in a seperate project, then I was thinking about this approach. Although it just seemed like an overhead.

I had types.d.ts but it was not being brought over either, so I was unable to import the types from the package.

Thanks for the reply! And I appreciate you reaching out.

As @ForsakenHarmony has said, generally types should be defined in a .ts file.

.d.ts files are only used at build time, and don't produce any file. I guess this is why rollup doesn't include it in the dist.

.d.ts files are used to describe files that aren't TypeScript, or have a DefinitlyTyped entries. And as such the way you think about them are:

_I have a node_module called ./types, which is a .js module. But I would like TypeScript to give my type hints, and check my code at compile time, so im going to create a types.d.ts file to define this module being imported. But at runtime (and runtime being JavaScript), still treat that ./types as a node_module and import it accordingly._

__TL;DR:__ Rename your types.d.ts -> types.ts and you'll be good to go, and you'd more spec compliant to its meaning.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

adriengibrat picture adriengibrat  路  4Comments

breadadams picture breadadams  路  3Comments

belozer picture belozer  路  3Comments

developerdizzle picture developerdizzle  路  5Comments

rzkhosroshahi picture rzkhosroshahi  路  5Comments