not support [email protected]

[nnecec]

Throw error when update parcel to 1.10. Look like typescript compile failure. Maybe because [email protected] support babel@7, I don't know ..

[cyntler]

Exactly. This is happening. When I made the parcel-bundler downgrade to 1.9.4 everything works fine.

[mironal]

You can use tsc -noEmit instead of parcel-plugin-typescript.

Because parcel-plugin-typescript is mainly used only for type check.

ex.

{
    "scripts": {
        "build": "parcel build src/index.ts --target node"
    }
}

to

{
    "scripts": {
        "build": "tsc - no Emit && parcel build src/index.ts --target node"
    }
}

[mnn]

Yeah, it seems TypeScript files aren't being processed by tsc.

$ npx parcel build src/index.ts
🚨  SyntaxError: /xxx/src/index.ts: Unexpected token, expected ";" (7:5)

   5 | import * as fp from 'fp-ts';
   6 | 
>  7 | var a: string = '';
     |      ^

Versions: [email protected] [email protected]

[cruhl]

I'm having the same issue

[TkDodo]

You can use tsc -noEmit instead of parcel-plugin-typescript.

As far as I know, absolute imports are not working with parcel if you are not using parcel-plugin-typescript, so I need that plugin to work. Unfortunately, I am having the same issue when upgrading to 1.10.3

[mmmeff]

This is a really bad bug. First noticed it while learning Parcel on codesandbox, attributed it to the platform, started a new project locally and I'm still having issues compiling typescript files. Any typescript-specific syntax breaks the compiler. Both .ts and .tsx file extensions break parcel.

[joseluisq]

Any updates? I have the same issue:

  "parcel-bundler": "^1.10.3",
  "parcel-plugin-typescript": "^1.0.0"

[mitchellnemitz]

I solved this issue by abandoning this plugin and instead installing @babel/preset-typescript and babel-plugin-module-resolver with this bit of config in my .babelrc:

{
    "presets": [
        ...
        "@babel/preset-typescript"
    ],
    "plugins": [
        [
            "module-resolver", {
                "alias": { ... },
                "root": ["./same/as/tsconfig.json/baseUrl"],
                "extensions": [".js", ".jsx", ".ts", ".tsx"]
            }
        ]
    ]
}

[benpolinsky]

@mitchellnemitz this "works" but still doesn't report errors on build.

Edit: unless I am missing something, which could very well be the case :)

[quantuminformation]

same issue?

https://github.com/fathyb/parcel-plugin-typescript/issues/13#issuecomment-457195549

[mitchellnemitz]

@benpolinsky if you add "noEmit": true to your tsconfig.json you can just run tsc in parallel with your build to find any type errors. The point of using babel instead of typescript directly is just to speed up build and move type checking to more of a lint-type situation that can be run in parallel, which can be a good or bad thing depending on your goals and mentality.

[benpolinsky]

@mitchellnemitz Thanks for explaining the thinking behind the decision. From my perspective, it'd be great to have as part of Parcel's zero-config philosophy since it's pretty crucial to TypeScript. JSLint isn't essential to JS, but type checking is pretty essential to TypeScript - that's my line of thought anyhow.

[mitchellnemitz]

@benpolinsky Hrm, I actually agree. I'm just so used to solving my problems by piling on tooling and configuration that I almost forget what Parcel is supposed to be.

I'm going to take a pass at creating a Typescript plugin that compiles via Babel but runs type checking with tsc -- hopefully that approach will keep the builds fast while still reporting on type errors, and hopefully the plugin code itself will be minimal and I can pass most of the inevitable issues upstream 😛

[mitchellnemitz]

For what it's worth, you could just go with my approach combined in an npm script like so until I get an alternative plugin together: https://github.com/fathyb/parcel-plugin-typescript/issues/59#issuecomment-429499815

[benpolinsky]

Here's what I cobbled together the other day, seemed to work okay. Just building off the included TS Asset:

https://gist.github.com/benpolinsky/a968b18b82ae2805f742e3cc04cf9417

Basically using the examples from the TypeScript compiler API to list diagnostics but not emit the TypeScript. Then let parcel + Babel do their thing.

[quantuminformation]

My project was fine with webpack, can anyone advise how to fix parcel here:

https://github.com/QuantumInformation/youtube-space-invaders/tree/b

[mitchellnemitz]

@QuantumInformation can you be more specific as to what error you're experiencing? Is it that your Typescript isn't compiling with this plugin? If so, try one of the solutions above involving Babel 7.x and tsc in an npm script. If it's something else, you should open an issue in the relevant repository.

[quantuminformation]

This is the error

ill try the above, i thought parcel was 0 config..

[mitchellnemitz]

If you're using Typescript, you're beyond the zero-config functionality of Parcel. It has out of the box support for JS / CSS / HTML and a few other things, but not TS. Set up Typescript through Babel and create an npm script as suggested above and you'll be off to the races again.

[quantuminformation]

dang, might go back to webpack.

[quantuminformation]

@mitchellnemitz what do I put in place of "alias": { ... },

[mitchellnemitz]

alias in the module resolver context is analogous to paths in tsconfig.json -- i.e. a list of path mapping entries from module names -> locations relative to your baseUrl. In Webpack this is resolve.alias.

See Module Resolution documentation for more details: https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping

Most people won't need the alias option, but it's useful to point out how it fits in for completeness.

[rfgamaral]

(...) if you add "noEmit": true to your tsconfig.json you can just run tsc in parallel with your build to find any type errors.

I understand the reasoning behind this to implement type checking before building and making sure code is not emitted if there are errors.

The point of using babel instead of typescript directly is just to speed up build(...)

But I don't quite understand the need for this, especially when paired with this:

If you're using Typescript, you're beyond the zero-config functionality of Parcel. It has out of the box support for JS / CSS / HTML and a few other things, but not TS.

Which is not quite true!? I mean, Parcel has [partial] support for TypeScript out of the box, it just doesn't do type checking. But we can work around that issue with tsc, before running parcel.

So, what are the real advantages of moving to Babel instead of TypeScript for compilation besides "speed"?