0
207
VistasIs it possible to create an Electorn application that compiles only to the platform code?
I will clarify my question for a very specific use case.
Let's say, I've designed my code as follows:
And this is the content:
src/inner/inner.darwin.ts:
export default function logger() {
console.log('Darwin Logger');
}
src/inner/inner.windows.ts:
export default function logger() {
console.log('Windows Logger');
}
src/inner/inner.ts:
NOTE the export default - it is mandatory
import LOGGER from '???????????';
export default class A {
public static logger() {
LOGGER();
}
}
So basically, when I compile Windows code, I want to import the inner.windows.ts code. When using Mac code - inner.darwin.ts code.
I do know I can control excluded files in tsconfig.json.
So when I'm going to create Windows application I will code:
"exclude": ["**/*.darwin.ts"]
And when I will create Mac one:
"exclude": ["**/*.windows.ts"]
However, it did not help for resolving the import issue.
I do know I can run code depends on the underlying platform using process.platform, but it does not do the job. I want the output Windows application to be more small of size - and ignore any Mac code. If I'd use this process.platform - the Mac code would still exist in the underlying Windows application.
Any advice?
Can Webpack do something to help? I am open for any code changes as long as the code is well defined and split, and the final outcome is that I have only Darwin code and Windows code
1 Respuestas
Responde la pregunta0
So the solution is quiet simple. All I had to do is using a Webpack plugin.
The best Plugin to fit this task is NormalModuleReplacementPlugin which is provided out of the box by Webpack itself.
The exclude in tsconfig.ts is no longer reasonable within this solution.
Simply provide the following plugin:
new webpack.NormalModuleReplacementPlugin(
/darwin/,
function (resource) {
resource.request = resource.request.replace(
/darwin/,
'windows',
);
}
),
This will override any import to a darwin file into a winodws file.
Now, in development, both files exist - but in compilation - only either of them will exist.
inner.ts simply becomes:
import LOGGER from './inner.darwin';
export default class A {
public static logger() {
LOGGER();
}
}
Of course that could be quiet cumbersome to go into webpack.config.ts each build, so we could definitely run some extra webpack script to decide upon which underlying build to go with, for example:
const appTarget = env.APP_TARGET || 'darwin';
And then simply use this variable within the plugin, and run your npm build script providing an APP_TARGET argument.