cli
cli copied to clipboard
aurelia
generate TypeScript d.ts for aurelia-cli
reason
Currently when selecting TypeScript as a transpiler the build scripts are also generated in TypeScript, but IDE can't do much without the typescript definitions.
I agree. I'm not sure how best to handle this yet. There's more to it than the cli d.ts. We can certainly create one of those. But, we need gulp and all the plugins really.
@EisenbergEffect,
But, we need gulp and ...
if You referred to TypeScript IDE support for writing gulp files, then see #183
This also affects the generators since without the cli .d.ts the generator code is a mess
The cli api is a bit unstable currently. We can certainly add a d.ts just remember this is alpha and it is likely to change over the next few months.
Maybe au would build but my IDE (Intellij IDEA) highlights all of the failed classes and won't do the automatic build-as-you-go with classes broken
Ok, that compilation is done on the fly, automatically by the Aurelia CLI itself, as needed. So, there's no need to have the ide touch that. However, we can work to address this in the future. Is there a way to have your IDE ignore that folder for now?
Yes, I can ignore it and just use the CLI. Seeing the red is just an annoyance, I suppose, but I've been trained by my IDE to go and fix things highlighted in red.
I currently have this problem with Visual Studio. As soon as I press F5 I get the build errors and then the CLI will also no longer build with the below error.
(function (exports, require, module, __filename, __dirname) { define(["require", "exports", 'gulp', 'gulp-changed-in-place', 'gulp-plumber', 'gulp-sourcemaps', 'gulp-notify', 'gulp-rename', 'gulp-typescript', '../aurelia.json', 'aurelia-cli'], function (require, exports, gulp, changedInPlace, plumber, sourcemaps, notify, rename, ts, project, aurelia_cli_1) { ^
ReferenceError: define is not defined
at Object.
Am I doing anything stupid?
@beatsm You say that you have build errors when you build within Visual Studio. I don't know if it is the same issue but I cannot build using VS due to an older tsc version
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.8\tsc.exe --project "C:\Users\sro\Documents\Visual Studio 2015\Projects\AureliaTestCli\src\AureliaTestCli\tsconfig.json" C:\Users\sro\Documents\Visual Studio 2015\Projects\AureliaTestCli\src\AureliaTestCli\error TS5023:Build:Unknown compiler option 'lib'.
I don't know if it is possible to update the version of tsc used by msbuild. The official package is still 1.8 Ideally, it should be possible to entirely disable TS compilation, but I haven't found anything about that.
@srollinet @beatsm Visual Studio 2015 by default will try to compile Typescript on build. If you're missing any Typescript definition files, like aurelia-cli which are not on definitively Typed or in the project, you won't be able to build. Since the cli will handle all the client-side building (compile typescript, css, bundle, minify, etc) you should disable Typescript compilation by VS anyway. It's not well documented but instructions are here: http://www.philipholly.com/post/148366570426/aurelia-typescript-errors-and-how-to-get-visual
Also on that article there are instructions on how to upgrade Visual Studio to Typescript 2.0.0.0-beta.
@pholly thanks.
This works a treat. http://rostacik.net/2015/08/14/how-to-disable-building-of-typescript-files-in-visual-studio-2015/
Regards
I'll mention, that this is just a workaround, that doesn't help us to write Gulp files or change/customize/add aurelia-cli generators written in TypeScript.
I would very much like to see a type definition for the cli. Is there any progress on this topic? Does it have any priority?
I'm setting up a new project and we are using ts lint, we do not allow code without type declaration. I now have to ignore all the code in the aurelia project since i'm missing type definitions and its not a trivial task to create them (I would have to make lots of guesses since the code is not extremely clear to me on types and flow). I auto generated the basics for the cli but it's far from complete. This will help a bit when writing new generators/tasks but a proper d.ts would improve quality allot imho.
As a side question are there any plans to (re)write the cli project in TS?
We've been discussing moving the entire CLI to TypeScript and some general refactoring across the board as well. @huochunpeng and @jwx might have some thoughts on that. It's not the top priority at this moment.
@michaelw85 If you've got a partial d.ts file that you've generated, we could bring that into this project to help other community members and then we could just patch that along the way as needed until we move this library to TS.
Ok good to hear, if I can help rewriting some part to ts please let me know where to start.
For the generated d.ts file, sure I can share but its very crude. Its missing methods and defaults all params and return types to any. Would it be an idea to put this in a types package (@types/aurelia-cli)?
Here's the auto generated file: aurelia-cli.d.ts.txt
I only edited a single method with different types I think.
Let's hear what @huochunpeng and @jwx think is best at this point since they are our core team members who usually end up working on the CLI most.
I know nothing about TS (one less problem for me than all of you) :-) But I don’t mind someone to convert the code base.
The main problem of the conversion: we don’t have enough test coverage.
@huochunpeng Good time to start 😉 I was skeptic about the benefits at first but I feel like plain JS is holding me back these days. TS helps me improve overall quality in my code, it also helps me be more productive because of improved intellisense.
To start somewhere I think we could try and setup the typescript compiler to allow js and see if we could output the current setup as-is. This would already enable some generation of d.ts files and it immediately allows us to start using TS by "simply" changing the extension of files (and making it compatible this is the hard part ofc). But a good start could be to see if the unit tests can be setup in TS this should not impact the code I guess, not sure if this is viable though. After that slowly changing files to ts and adding type definitions as a follow up.
@michaelw85 If you are interested to give this a shot, we're open to that. My guidance would be to try to make the smallest possible initial PR to get things in place and working. Minimal changes at first. Send us a PR for that, and we can review and discuss. Once the initial setup is in place, we can then do small, successive PRs to chip away at the conversion. I'd like to avoid a "big bang" gigantic PR if we can.
Yes I would love to try! I totally agree on the agile approach, I will try to refrain as much as possible from editing existing files for the first setup.
My guidance would be to try to make the smallest possible initial PR to get things in place and working.
@michaelw85, if you plan to start with the PR containing just the autogenerated file you linked previously, then i suggest you to mark the unknown types so later it whould be possible to distinguish parameters and return types that are really any vs those that are just unknown. So initially you could just add following as a first line
declare type undiscovered = any;
and replace all other occurrences of any with undiscovered - this should be simple enough and serve as an invitation to other Aurelia community members to refine types at their own pace without requiring to await rewriting this repo to TS or needing to refine everything or wast time on figuring if specific parameter/return value is really any or just unknown for now.
aah, by the way, if anyone is interested in solution how i managed to get rid of IntelliJ IDEA warnings from TypeScript files from aurelia_project/tasks folder after generating new aurelia project with TS, then:
- i created aurelia_project/tasks/tsconfig.json:
{
"compileOnSave": false,
"compilerOptions": {
"resolveJsonModule": true,
"lib": [
"es2017"
]
},
"include": [
"./**/*.ts"
]
}
- added some devDependencies to package.json:
"@types/browser-sync": "0.0.42",
"@types/connect-history-api-fallback": "^1.3.1",
"@types/debounce": "^1.2.0",
"@types/gulp-plumber": "0.0.32",
"@types/gulp-tslint": "^4.2.0",
"@types/gulp-typescript": "^2.13.0",
"@types/gulp-watch": "^4.1.34",
"@types/merge2": "^1.1.4",
"@types/plugin-error": "^0.1.0",
- ignored couple of packages in tasks TS files using
// @ts-ignorebefore import line (such as gulp-changed-in-place and gulp-notify) - did some minor changes like replacing
project.build.copyFileswithproject.build['copyFiles']to make TS compiler happy
It was pretty painless :) Sadly i didn't have time to investigate how to improve the CLI to turn that knowledge into PR for others to benefit
My guidance would be to try to make the smallest possible initial PR to get things in place and working.
@michaelw85, if you plan to start with the PR containing just the autogenerated file you linked previously, then i suggest you to mark the unknown types so later it whould be possible to distinguish parameters and return types that are really
anyvs those that are just unknown. So initially you could just add following as a first linedeclare type undiscovered = any;and replace all other occurrences ofanywithundiscovered- this should be simple enough and serve as an invitation to other Aurelia community members to refine types at their own pace without requiring to await rewriting this repo to TS or needing to refine everything or wast time on figuring if specific parameter/return value is really any or just unknown for now.
That is a very good suggestion! Definitely one to keep in mind. For a first PR I will only focus on enabling writing TS and get all code to run as-is. So only adding a tsc build. I will have a look if I can already compile with a similar auto generated d.ts else I will manually include it at first.