Skip to content

Add getLanguage() helper for project typescript | javascript default and settings#633

Closed
thedavidprice wants to merge 9 commits intomainfrom
dsp-add-language-target-helpers
Closed

Add getLanguage() helper for project typescript | javascript default and settings#633
thedavidprice wants to merge 9 commits intomainfrom
dsp-add-language-target-helpers

Conversation

@thedavidprice
Copy link
Copy Markdown
Contributor

@peterp How's this for a first attempt at TS?

The goal is to create a helper that a) can return the default project language based on a check for tsconfig in root or b) return a redwood.toml config target if given, and if not falls back to project default. I'd like a helper like this to be used for all generator commands (when converted to TS support) as the default setting for the command language option.

One high-level question: I'm assuming there should be one config for the entire project, but should this (somehow) take into account each Side and do a similar a) what's the Side's default, e.g. does tsconfig exist and b) does the Side have a language target config in redwood.toml? I've been thinking too simply about hybrid language projects -- it's not the project that can be hybrid as much as each side can be a hybrid. Right?

Next Steps:

  • what should the type be for getLanguage? unknown passed lint, but was also a statement of my level of understanding 😉
  • this will need a test, which I'll add once you give the code a 👍

@thedavidprice thedavidprice requested a review from peterp May 31, 2020 07:24
@peterp
Copy link
Copy Markdown
Member

peterp commented May 31, 2020

This looks good, but I think a bunch of your questions lead me to think that this should probably not be a configuration option, but rather something that's determined by a <projectDir>/tsconfig.json file.

We can then create a ./web/tsconfig.json and ./api/tsconfig.json files on each side that extends from the root configuration.

I would love to see a isTypeScript method in src/project.ts that returns false if a <projectDir>/tsconfig.json file isn't found, which implies that it's a JavaScript project.

@thedavidprice
Copy link
Copy Markdown
Contributor Author

@peterp I've created project.ts with three methods:

  • getSides() returns an array of existing sides
  • isTypescript(side = '') checks language of side; if no side given, checks base
  • hasDb(prismaSchemaCheck = false) checks for prisma/; if 'true' is passed, check for schema.prisma. This currently feels redundant, but I was thinking ahead to case where prisma/ dir is named db/ and project might be using a different DB solution

I tested all these on Windows (including a project with space in base path) and confirmed they are working correctly. (This is also why I’m using path.join everywhere.)

  • Thoughts about these in general and how they are structured?
  • I took a stab at the test. Thought I could use the existing fixture files/structure and mock getPaths(), but it's not working as implemented. Not even sure if this is the correct approach.

@peterp peterp self-assigned this Jun 14, 2020
@peterp
Copy link
Copy Markdown
Member

peterp commented Jun 15, 2020

@thedavidprice It looks like things are failing here, do you want to fix those up and then I can review?

@thedavidprice
Copy link
Copy Markdown
Contributor Author

@peterp Ah, I had to remember where I left off on this one. Actually, the tests are where I needed help --> specifically mocking the paths (which apparently I left off trying to use existing fixtures): see __tests__/project.test.ts failing on L17 expect(getSides()[1]).toEqual('web')

But before you work on helping with the tests, why don't you review the code in project.ts to see if it's even anything close to what you were thinking in the first place. And it's been more than a week so possible everything's already changed, right? 😆

@peterp peterp changed the base branch from master to main June 19, 2020 15:33
@peterp peterp removed their assignment Jun 30, 2020
/**
* Returns array of a project's existing sides
*/
export const getSides = (): string[] => {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a big fan of this lint rule that forces you declare return types. Inferred types are better for long term maintenance because you don't have to change them as function definition changes.

Suggested change
export const getSides = (): string[] => {
export const getSides = () => {

import { getPaths } from './paths'

// TODO: make this dynamic
export enum SidesEnum {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a Set data structure seems more reasonable for this.

@peterp
Copy link
Copy Markdown
Member

peterp commented Jul 15, 2020

We decided that this functionality should belong in structure so I'm closing this off for now.

@peterp peterp closed this Jul 15, 2020
@peterp peterp deleted the dsp-add-language-target-helpers branch November 11, 2020 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants