[heft] - Heft commands supports argument to supply tsconfig.json path

[alfonsoar]

Is this a feature or a bug?

• Feature
• Bug

Please describe the actual behavior.

I have a use case where I would like to supply heft with the location of my tsconfig.json file. I work on a UI component library and each rush project is a UI component. Since each project is a library there are two places where TS code lives, src and demo. Think of something like this:

monorepo
└── components
    ├── ui-component-1
    │   ├── demo   <---- src code to help build the component lives here
    │   └── src    <---- Actual component source code lives here 
    └── ui-component-2
        ├── demo
        └── src

The challenge this setup posse is that there is no easy way to compile both demo and src to a different destination when using heft start or heft build. I would not want my "demo" code in the final bundle since this is used for local development.

What is the expected behavior?

If we could pass heft an argument to the proper tsconfig.json file, then we could create two different tsconfig.json files. One for development and one for production builds. I am imagining having something like this in my package.json

"scripts": {
    "build": "heft build --production --clean --tsconfig-path tsconfig.production.json",
    "start": "heft start --clean --tsconfig-path tsconfig.development.json",
  },

note: Not a huge fan of --tsconfig-path. Open to suggestions on what this should be.
note-2: The tsc CLI supports this with the --project argument.

I could then tell the tsc compiler to compile both demo and src for my development work but only src when I build my library.

Please let me know if you think this use case is valid and if so if you would be open to a contribution to this feature. I am happy to contribute this back.

[alfonsoar]

Closing this since I just noticed we have #2258

[BPapp-MS]

@alfonsoar I'm curious if this scenario would work as separate demo and src projects in your monorepo? With demo having a dependency on src? And if that wouldn't work, the reason it doesn't would be informative in terms of how to design a Heft/Rushstack solution to your scenario, whether it involves the ability to specify a tsconfig.json path or otherwise.

[alfonsoar]

@BPapp-MS - Thanks for the reply, separating the demo and src folder is a scenario that should work but might not be ideal. I think the ideal flow for us would be to have the ability to develop in both the src and demo and have the changes reflected on screen. (which I think we can do if they are separate packages but might require two watch servers?) Separating them into their own projects would also basically double the number of projects we have. We currently have around ~200.

I think having heft support this would be a nice to have but as you pointed out there are ways to get around this.

BTW what we currently do to "suppport" this is that we stick the demo folder under src and then just delete the demo folder from the output dir heft uses.

let me know if there is anymore info I can provide to help.

[BPapp-MS]

Correct me if I'm wrong but I'll summarize what I understand: Your specific problem, which different tsonfigs would solve, is that you'd like to be able to structure one project into two parts, such as with source files in the src and demo directories, which could build independently and output to two separate directories. The demo directory, for example, contains resources useful for development but shouldn't be included in the final package. And I can imagine, if either directory were to get large, it would be nice to be able to iterate on one and not rebuild the other..

In terms of keeping the demo code out of the resulting package, I'm curious if the .npmignore file or the files property in package.json would work for you?

And just so you know, if you were to make the src and demo directories into their own projects, we are definitely looking into a multi-project watch feature which would allow you to do continuous development on both.

For context, one of the complexities of a feature like supporting multiple tsconfigs is that is creates challenges when it comes to creating a thoroughly optimized solution like heft is trying to be- each tsconfig packs a lot of customizability and having multiple would open the door for bad interactions between the tasks we're trying to support, and might offer a less-than-user-friendly solution for the problems it would fix. In reality multiple tsconfigs are used often as a workaround for various different limitations of the compiler, Jest, and other software, and it could be more practical to identify, implement, and support the solutions to those problems through Heft, if possible.

[alfonsoar]

Hi @BPapp-MS - Yes your summary of my specific issue is correct. The only thing I would note is that the "demo" folder does not contain actual source code. What it contains is an implementation example of that package's src directory. In other words if I have a package called "Label" (for simplicity lets say Label renders a div and takes one prop called text). In my "demo" folder I would have a TS file that imports that Label component and supplies it with the prop text.

In regards to your suggestion of using the "files" property in our package.json we actually do use this feature and it would be a nice way resolving this issue with the exception of one minor cosmetic thing. For example, I could add something like this to our tsconfig.json in order to have it also compile the "demo" folder and the "src" folder

"include": ["./src/**/*", "./demo/**/*"]

And then have this in our package.json

"files": [
    "dist/src",
  ],

Which should produce a final package with someting like this

package/
|-- CHANGELOG.md
`-- dist
    `-- src
        |-- index.d.ts
        `-- index.d.ts.map

Which is almost what we would want... Ideally I would like to remove the "src" from the final package and just have it be

package/
|-- CHANGELOG.md
`-- dist
    |-- index.d.ts
    `-- index.d.ts.map

Again thank you for the suggestion you have provided so far and for taking the time to understand this usecase.

[BPapp-MS]

Can definitely appreciate the use case- index being in the dist file is a common paradigm