Support for type definition files #188
Conversation
|
Forgot to mark this as "draft". It's not ready yet. |
| @@ -95,6 +99,20 @@ export class Body extends Statement { | |||
| return result; | |||
| } | |||
|
|
|||
| getTypedef(state: TranspileState) { | |||
There was a problem hiding this comment.
Why not having a "transpilation mode", even as a static flag somewhere, to control that instead of doubling half the transpilation logic with those getTypedef methods?
There was a problem hiding this comment.
I considered that, but most expressions and statements will not emit any typedef information. Having a separate function allows me to detect which items we should even walk in the first place (and avoid needless transpile recursing). See
if ('getTypedef' in statement) { a few lines below this comment.
Also, if most of the transpile function can be reused, I'm already calling it within the getTypedef method so we don't actually duplicate any logic. (see comment statement). Meanwhile, something like a NamespaceStatement doesn't actually transpile itself, so that's where having a separate function keeps the logic clean between the two concepts (transpile and getTypedef). Or ClassStatement, whose transpile function is extremely complex and doesn't have any similarities with what its typedef would look like.
Export `BscType` type for `BrsFile | XmlFile`
| this.needsTranspiled = true; | ||
| } | ||
| this.isTypedef = this.extension === '.d.bs'; | ||
| if (!this.isTypedef) { | ||
| this.typedefKey = util.getTypedefPath(this.pathAbsolute); |
There was a problem hiding this comment.
Feels a bit wasteful to calculate for every file - should it be undefined until it "has" a typedef?
There was a problem hiding this comment.
We need the key for every file right away because we use that key to subscribe to typedef file changes (add/update/delete of typedefs).
|
|
||
| let allDependencies = this.getAllDependencies() | ||
| //skip typedef files | ||
| .filter(x => extname(x) !== '.d.bs'); |
There was a problem hiding this comment.
Should they be replaced by .brs files?
There was a problem hiding this comment.
No, the .bs/.brs files are already there. For every .bs/.brs file, the XmlFile also adds the corresponding .d.bs file as a dependency during initialization (see this new block of code)
|
I believe this is functional enough for an initial release. I'm sure we'll run into some quirks, but luckily enough, this is an opt-in feature so it shouldn't have too many adverse effects for teams who aren't opting in to this feature. |
This adds support for loading type definition files (
d.bsextension).Notable changes:
emitDefinitionsis true in the bsconfig