Closed yankeeinlondon closed 3 years ago
"plugins": [
{ "transform": "typescript-transform-paths" }
{ "transform": "typescript-transform-paths", "afterDeclarations": true }
]
"plugins": [
{ "transform": "typescript-transform-paths" }
]
I have looked out the output of both the code and the types and it would appear that the path aliases have been transformed which is odd because I know that you needed both transforms to have this effect in the past. Has something changed?
I can see now that if I comment out the afterDeclarations
transformation (leaving just the default transform), it transpiles.
No, i take it back ... there are still path aliases in the type definitions. For instance:
import { AbcApi } from "@/abc";
export declare function getFromVuex<T>(ctx: AbcApi<T>): Promise<any>;
This project is open source and this experience can be easily reproduced by cloning: https://github.com/forest-fire/vuex-plugin-firemodel and using the @develop branch.
@ksnyde I suggest filing an issue on the typescript-tranform-paths
repo. It is doubtful that this is an issue with ttypescript
.
Please include the version number and steps to repro, and I'll have a look when I can.
yes I think you're right ... i hacked typescript's code to force my repo to build but I need a more graceful means. It seems more likely that it's in typescript-transform-paths
though and not the infrastructure that you're providing. Thanks for the quick return.
I have code which compiles without issue using
tsc
but when used withttsc
or Rollup with thettypscript
replacement. Mytsconfig.json
file is:This same repo and tsconfig used to compile but after updating a number of requirements (including Typescript to 4.1.3) it now fails with:
I have gone into Typescript's code and added code to pull out more information as I was completely confused by the message. When I hit an error condition, I now get a dump of the node's context which looks like this:
With my someone low resolution understanding this seems to suggest it's taking some issue with the
FirebaseAuth
symbol which is being imported from a package that does indeed export the given symbol. What i've noticed, however, is that if I use the newerimport type { symbol } from 'xyz';
this is where it seems to fall over.