search

feathers-plus / generator-feathers-plus

A Yeoman generator to (re)generate a FeathersJS application supporting both REST and GraphQL architectural concepts and their query languages.
https://generator.feathers-plus.com/
Other
44 stars 30 forks source link

Make tsconfig.json extensible #84

Closed eddyystop closed 4 years ago

eddyystop commented 6 years ago

"Matthias Max [3:42 AM] To add to the discussion: I write my services, hooks and so on in TS which gives me the best of both worlds: My own base typed and the amazing features of feathers. Feathers is well tested and has a long history of evolvement. No need to have „everything“ in TS. (edited)"

j2l4e [9:42 AM] He's right there. Everything's so complicated to generate because we're aiming for TS strictmode compat. The non-strict mode of TS is a lot more JavaScripty and a lot easier if you want to migrate a JS app (edited) it's just a matter of tsconfig.json/compilerOptions/strict being true or false, though. If you need to turn it off, it's easily turned off

eddyystop [10:00 AM] Is this an option to consider for the generator?!?

j2l4e [10:06 AM] Either that or we use the fact that tsconfig.json is extensible:

We can move everything that's in tsconfig.json now into tsconfig.base.json and create a new tsconfig.json that's never regenerated:

  "extends": "tsconfig.base.json",
  "compilerOptions": {
    // "strict": false
  }
}

users would be able to change the configuration if they have to yet regen/updates of tsconfig.base.json would still be possible

eddyystop [10:08 AM] A prompt is hard to miss, but an extension has more flexibility I would think those names are rather obvious

j2l4e [10:13 AM] "strict" is just a shorthand for enabling several strict mode options at once.

```"strict": true,                           /* Enable all strict type-checking options. */
// "noImplicitAny": true,                 /* Raise error on expressions and declarations with an implied 'any' type. */
// "strictNullChecks": true,              /* Enable strict null checks. */
// "strictFunctionTypes": true,           /* Enable strict checking of function types. */
// "strictPropertyInitialization": true,  /* Enable strict checking of property initialization in classes. */
// "noImplicitThis": true,                /* Raise error on 'this' expressions with an implied 'any' type. */
// "alwaysStrict": true,                  /* Parse in strict mode and emit "use strict" for each source file. */```

So you can go from non-strict to strict in small steps if you want to. So extension might be the better way to do this.

eddyystop commented 6 years ago

j2l4e [4:49 AM] @leob @luc.claustres @Matthias Max You can loosen typescript's configuration step-by-step to the point where you can even import JS files (allowJS flag). You can then introduce strict settings incrementally and make your code type-safe(r) in small steps. In "loose mode" everything feels quite JavaScripty but has inferred typing, thus stuff like this will be caught:



myVar = '7'; // 'string' not compatible with 'number'```
This might be a bug or it might be intended. If intended you'd add the proper type annotation:
```let myVar: string | number = 7; // myVar can be a string or a number now.

myVar = '7'; // totally works```
Or if it _really_ can be anything you go with 'any':
```let myVar: any = 7;```

Adopting TypeScript in parts only is totally possible and while you can make it really strict you can also get an ES6-ish experience out of it.

The feathers-plus CLI generates code that's strict-mode compatible out-of-the-box. But non-strict code can be added after tuning `tsconfig.json` a little. (edited)

j2l4e [5:07 AM]
bugs like this one https://github.com/feathersjs-ecosystem/feathers-localstorage/pull/76 just can't happen with TS, but I see that it comes at a price, especially when you do a lot of mixins or heavily overloaded functions, things can get verbose quickly.

luc.claustres [5:24 AM]
@j2l4e well the question about strong/weak typing is probably a endless one, I come from a C/C++ background and have an idea about what is strict typing, I switched over JS, MongoDB, etc. over the years because I feel a lot more productive with more flexibility, I think it is also a matter of your experience and your practices. A beginner can really do ugly things in Js that he cannot probably do with TS, so it might be good for him. I actually dream of a language that could adapt to each dev practices and evolution, as always context matters. I don't think what is often highlighted like "you cannot have this kind of bugs in TS or whatever strong typing language" is actually relevant. Among all bugs, theses ones are the exceptions not the rule (I can tell for instance that a lot of bugs in C++ come from memory management), otherwise almost no bugs would arise in C++ apps, and you cannot base you daily practice on an exception. IMHO testing is more important than the language so for the language choose what makes you efficient. (edited)

leob [5:27 AM]
@j2l4e That's also what I fear, the amount of "overhead", that's why I still didn't make the leap into TS yet ... this is what's holding me back ... besides, I'm still convinced that most errors/bugs are *not* caught by strong typing and that you still need unit tests anyway ... if you have a good set of unit tests (which you need anyway) then the argument for TS/typing also largely goes away (I think that *the* advantage of typing/TS is not safety but better support in your IDE, code navigation and refactoring)
I'm a longtime Java programmer so I have plenty of experience with strong typing, and my experience is that there are *lots* of errors/bugs that it does *not* prevent ... on the other hand the advantages (no doubt) are documentation, code navigation and refactoring ... so the pros of strong typing are different than what most people believe ... and by the way I see a lot of Java code going overboard with too much complicated typing (generics easily get complicated, annotations and so on are often getting in my way rather than helping me, etc) (edited)
In other words ... most bugs/faults are "dynamic" not "static" so you can't have the compiler (or any form of static analysis) catch them for you (well maybe theoretically but not practically)

luc.claustres [5:34 AM]
I would add that test coverage is never sufficient because designing test cases for one single input parameter is quite simple - but how do you design test cases for many different input parameters? This is really challenging and results in a combinatorial explosion of test cases. So the only thing you can do is real-word usage battle-testing with rapid user feedback cycles, if you think basically about it then this means that what you need is a language that make you deliver fast, whatever it is :wink:

j2l4e [5:43 AM]
@luc.claustres 'I actually dream of a language that could adapt to each dev practices and evolution, as always context matters.'

It's not like TS would keep you from doing things the JS way. You just have to do so explicitly. I'm not trying to promote TS beyond what it is, use whatever suits your needs best.

I agree with @leob that intellisense is a big part of what makes it valuable (https://medium.com/feathers-plus/feathersjs-get-work-done-faster-with-feathers-hooks-commons-typings-cad04551d0b2).

I agree that the more you're used to the libs you work with, the less valuable TS gets.
Medium
FeathersJS: Get work done faster with `feathers-hooks-commons` typings.
Don’t crawl the docs, write the code!
Reading time
2 min read
Sep 13th
https://cdn-images-1.medium.com/max/1200/1*3Sq9NGAGbhybnMYNv3NGXA.png

leob [5:45 AM]
@j2l4e Your article about the typings file for feathers-hooks-common is great ...

j2l4e [5:48 AM]
Thanks :slightly_smiling_face:

j2l4e [5:51 AM]
Generally I think TS is more valuable to teams than to loners. JS teamwork is convention-heavy and needs lots of documentation and TS brings code, convention and docs closer together in a way.

luc.claustres [6:00 AM]
Yes this is a part where it is valuable to speed up dev: class/function interface documentation, just like OpenAPI/Swagger for REST

leob [6:02 AM]
That's also a point, I'm doing most of my projects solo, so TS probably has less added value ... in a team environment TS and the structure it brings has a lot more value (edited)
In a team env I wouldn't hesitate to at least spend some time trying TS out

luc.claustres [8:05 AM]
Personally I doubt of this, I have spent most of my dev in teams around 3-10 people, never saw a real difference when using strong vs weak typing languages, always at least the same number of bugs :wink: The main differences IMHO come from the teams to be well-balanced in terms of experience/skills, CI/CD tools, fast integration/e2e testing, etc.