-
Notifications
You must be signed in to change notification settings - Fork 27k
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
Allow custom extensions #2699
Allow custom extensions #2699
Conversation
I would love to see this getting merged! |
@nelak could you add tests for this? ❤️ |
@timneutkens I added an integration test for the custom extensions showcasing the usage of JSX and I added a new sample |
@nelak than you very much! Looks good 👌 The test will help when Arunoda has time to take a look at it 👍 ❤️ |
@timneutkens @arunoda Anything else I can do to help so this can be merged |
Please, add integration sample for the JSX extensions showcasing in context of Firebase-Function hosting specificity! |
If there is anything blocking this I would love to help |
This is looking pretty good for us, except that static HTML export is broken:
This file probably needs to be
|
also _document.tsx is ignored, reproduction |
@paulcbetts Can you provide me some context or sample and I'll try to take a look at it when I can |
@paulcbetts I just gave this a try and at least for the with-typescript example you can get it to build and export properly the first time, excluding the out folder in the tsconfig.json will avoid it being recompiled on subsequent runs. "exclude":[
"node_modules",
"out/**"
] |
@nelak What {
"compilerOptions": {
"target": "es2017",
"module": "commonjs",
"moduleResolution": "node",
"declaration": true,
"sourceMap": true,
"stripInternal": true,
"experimentalDecorators": true,
"pretty": true,
"noFallthroughCasesInSwitch": true,
"noImplicitAny": true,
"noImplicitReturns": true,
"forceConsistentCasingInFileNames": true,
"strictNullChecks": true,
"jsx": "react",
"lib": [ "dom", "es2017" ]
}
} Another option you could try is to disable compiler errors during export entirely, since build will be picking them up already |
@paulcbetts I've updated the PR to include the sample with the export functionality, which should work. {
"compilerOptions": {
"target": "es2017",
"module": "commonjs",
"moduleResolution": "node",
"declaration": true,
"sourceMap": true,
"stripInternal": true,
"experimentalDecorators": true,
"pretty": true,
"noFallthroughCasesInSwitch": true,
"noImplicitAny": true,
"noImplicitReturns": true,
"forceConsistentCasingInFileNames": true,
"strictNullChecks": true,
"jsx": "react",
"lib": [ "dom", "es2017" ]
},
"exclude":[
"node_modules",
"out/**"
]
} |
Any ETA on this :/ ? |
This should be merged asap |
I need this for a project that I'm going to be using TypeScript for, and I'm willing to spend time on this if it helps. If there's anything I can do to help speed up the merging of this PR, let me know. |
just want to remind that _document.tsx is ignored |
join(i, 'index.js'), | ||
i + '.json', | ||
join(i, 'index.json') | ||
...getPagesPaths(config.pagesExtensions) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why use a generator here 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because I wanted to leave open the possibility of handling multiple extensions.
Let say you want to support ts, tsx, jsx, etc... this avoids having to concat each of the combinations just having the generator yield all of the possibilities, since the generator is iterable you can concat it as shown above.
|
||
module.exports = { | ||
// Add extensions | ||
pagesExtensions: [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be more convenient for users to be able to specify extensions as .${ext}
?
@nelak @valorloff @ulrikstrid @paulcbetts @BjornMelgaard @lednhatkhanh @kulshekhar Contributions are very welcome ! |
@D1no just curious - is that project used in production by anyone at all? I mean, it doesn't have a single test (which makes the travis badge somewhat baffling) |
@kulshekhar yes, the project comes from an production environment. We do use it in an internal environment for a client and are very happy. And soon will lay over our own system on top of it. And of course by noozle. Anyhow, the project is fairly young. But since it is build completely on top of well tested frameworks (React 16, React-Router, Webpack) with a very thin layer of stringing those together, without project proprietary implementations, E2E tests are something that should come in as soon the version settles. The leap forward here is really through React 16 hydration and React-Router v4 ability to create a AST of all routes used in the code. I'd suggest just to try it out. |
@D1no why do you say this pull request is dead? I don't see any mention of that. What am I missing? |
Is this pull request still in consideration? |
@nelak Any update on getting this merged in? |
@JeremyJonas I once went through some bits of the code with @timneutkens so my guess is that this or some kind of variant will make it in at some point in the future. |
@timneutkens Are there any further updates on this, you got for us? |
647a42d
to
33f8f28
Compare
any updates? 😿 |
This is superseded by #3578 |
…ary/examples/with-typescript Waiting for vercel/next.js#2250 and vercel/next.js#2699 and vercel/next.js#2391 to land to add proper support via Webpack
#2391 This PR adds support for custom extensions (.ts .tsx) based on the previous proposal: https://github.com/zeit/next.js/pull/2250/files#diff-0f2f34c098f5954f99483c9bd61e439dR51
Hope this also helps support .jsx