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

Production ready without cache #780

Closed
smolijar opened this issue Feb 11, 2019 · 3 comments
Closed

Production ready without cache #780

smolijar opened this issue Feb 11, 2019 · 3 comments
Labels
question Support requests. We tend not to answer these on Github. Nowadays I convert to Discussion instead.

Comments

@smolijar
Copy link

I am aware, this has been addressed in #104 and #653 and before I get trashed for that, I want to point out that PR #701 changes a lot ☝️

Since I still could not find any up-to-date info about this (e.g. expected to find in readme), what is the current state of cache? As I ran through the implementation I noticed there is an in-memory solution implemented at the moment.

Is it something that would have impact on the production usage, or it is of no importance?

@blakeembrey
Copy link
Member

In production, I'd recommend using --transpile-only. In general, it shouldn't affect much - most likely the production run will be the first execution of the code anyway, so using a cache isn't particularly useful there. It's meant to be more useful in development, e.g. repeated execution of similar code. Unfortunately there is a bug in the naive cache - for TypeScript and type checking it should have been taking into account a recursive hash of all dependencies, not just its own file.

@blakeembrey blakeembrey added the question Support requests. We tend not to answer these on Github. Nowadays I convert to Discussion instead. label Feb 11, 2019
@ScreamZ
Copy link

ScreamZ commented May 2, 2019

Hello @blakeembrey, thanks for your great answers. Currently I'm using it in development and I consider using it in production only for one case…

I'm using .graphql files and they are living in the same directory as my sources, which is cool for module pattern and single responsability files.

Using ts-node would allows me to prevent copying files, in the build process ? What do you suggest in such case ?

Regards

@blakeembrey
Copy link
Member

@ScreamZ Typically I create a directory a directory at the root of the project that both can import upward from (e.g. ./{src,dist,assets}), or I have a step after the compiler that'll just copy the files I care about from src into dist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Support requests. We tend not to answer these on Github. Nowadays I convert to Discussion instead.
Projects
None yet
Development

No branches or pull requests

3 participants