Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove tsconfig.json's "scripts" directory assumption #6217

Closed
chrishensel opened this issue Dec 23, 2015 · 4 comments
Closed

Remove tsconfig.json's "scripts" directory assumption #6217

chrishensel opened this issue Dec 23, 2015 · 4 comments
Labels
Duplicate An existing issue was already created

Comments

@chrishensel
Copy link

Hi, may I ask whether or not this can be made more flexible?

We have a project structure that puts the app's content inside the wwwroot/app directory that also contains the HTMLs etc, so having a seperate, forced "scripts" directory which outputs there is nothing more than an (unnecessary?) workaround.

The structure is like the following:

- wwwroot
  - app
    app.ts
    - module
      module.ts
      - controllers (*.ts)
      - services (*.ts)
      - views (*.html)
  index.html    

It would be great to have the tsconfig.json just in the "app" directory and it then compiles all .ts that are anywhere below that path, like it is the case with the tsconfig right now, however forced to expect them in the "scripts" dir.

Honestly, I think compile-on-save seems unnecessary given the presence of a tsconfig file. The regular way seems way better since when building the project it compiles the TS if missing, compile-on-save seems not to (plus you'd have to expect team members to make sure to enable it and go through all their files).

It would be a great help to be able to drop a tsconfig.json in any directory, not just the (seemingly) hard-coded "scripts" directory, or at least being able to adjust this path.

I tested this with the RC 1 Update 1 and it is quite unflexible there. If there is progress made in that area, please let me know.

Thanks in advance and best regards,
chris

@paulvanbrenk
Copy link
Contributor

This is something we're changing for the next version of the TypeScript tools. See e.g. #4714. So closing this as a duplicate of that more general request.

One note: the general guidance for ASP.NET v5 is to keep all source files outside the wwroot folder.

@paulvanbrenk paulvanbrenk added the Duplicate An existing issue was already created label Dec 23, 2015
@chrishensel
Copy link
Author

Hi, thanks for the heads-up! Also thanks for noting the guidelines, I was not aware of that. Could you please point me to the guidelines, so I can read up on the whole wwwroot topic?

Thanks again and have a merry Xmas!

@paulvanbrenk
Copy link
Contributor

I don't think there is actually guidance yet.. (I may have to write that myself), but here are some useful docs:

http://docs.asp.net/en/latest/conceptual-overview/understanding-aspnet5-apps.html

https://github.com/Microsoft/TypeScript/wiki/Using-TypeScript-With-ASP.NET-5

@chrishensel
Copy link
Author

Thanks for your response!

Maybe just as a well-meant suggestion for the future, would it be possible for us developers to have a short "best practices" document (or similar), which quickly outlines the most important Do's and Don'ts? They would be great to ship with the RelNotes to get a quick glimpse...

That's actually something that I'd really like to have, since the way how to use vNext has changed somewhat from alpha stage to now, and especially from the betas to the RC - for example, the use of "wwwroot" is now discouraged, but wasn't explicitly too long ago :), and at no point in the past have I seen a comment on the "tsconfig.json" stuff etc. (or maybe it hid itself before me).

In any case, thanks for your efforts and keep it up, I like it!

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

2 participants