Devon Govett
Devon Govett
But with the change to `import *` rather than only the default, wouldn't this now have the same issue?
> should the starters adhere to this? For some reason they are checked during tsc. did you try adding it to the "exclude" list?
> unless we want a separate typecheck for it that doesn't do module boundaries I thought that was what you were asking. The starters do have their own separate tsconfigs...
Yes, unless we want to fix all the `as any`. I don't think that would be good to publish in our docs :D Let's figure out how to exclude these.
I guess the input is also invalid here though? As you said, property rules are only allowed at the top-level, so I don't think we should hoist them either. As...
interesting, I'm not sure why one is an error and one is a warning. I will consider that the bug here - they should probably both error unless errorRecovery is...
Would a hash of the input file contents work or do we really need to use an output hash after all transformation? We already have an `asset.hash` property that could...
I would recommend, if we can, avoiding adding .js config support for this very reason, along with the issue that JS configs cause files that use them to be un-cacheable....
I don't understand why the npm registry would have that extra script. It doesn't not appear in the package.json https://unpkg.com/browse/@parcel/[email protected]/package.json
Thanks for working on this! 1. Yes, we generally prefer integration tests. This lets us more easily change the implementation without breaking the tests (we reused a lot of tests...