This would be a "nice to have" feature. Enabling us to have some Javascript create a configuration object that is then exported.
Use case: My local development server (preview server) has changing IP addresses and ports depending on the machine they run on. Having IP and port configuration in .env and then the javascript retrieve that via dotenv to create "frontMatter.preview.host": "http://192.168.1.201:1313" would increase the portability of the configuration.
Something like this:
require('dotenv').config();// load environment variables from .env file
constenvvars={ip:process.env.IP_ADDRESS||'127.0.0.1',// use IP address from environment variable or default to localhost
port:process.env.PORT||3000// use port from environment variable or default to 3000
};constconfig={// other configs
"frontMatter.preview.host":"https://"+envvars.ip+":"+envvars.port// other configs
}module.exports=config;
I am not sure in how far this breaks the concept of extensions inside .frontmatter folders, but this would be only for the frontmatter.json file in the root of the project.
This would be a "nice to have" feature. Enabling us to have some Javascript create a configuration object that is then exported.
Use case: My local development server (preview server) has changing IP addresses and ports depending on the machine they run on. Having IP and port configuration in `.env` and then the javascript retrieve that via dotenv to create `"frontMatter.preview.host": "http://192.168.1.201:1313"` would increase the portability of the configuration.
Something like this:
```js
require('dotenv').config(); // load environment variables from .env file
const envvars = {
ip: process.env.IP_ADDRESS || '127.0.0.1', // use IP address from environment variable or default to localhost
port: process.env.PORT || 3000 // use port from environment variable or default to 3000
};
const config = {
// other configs
"frontMatter.preview.host": "https://" + envvars.ip + ":" + envvars.port
// other configs
}
module.exports = config;
```
I am not sure in how far this breaks the concept of extensions inside `.frontmatter` folders, but this would be only for the frontmatter.json file in the root of the project.
<!-- github-sync-id:1645778335 -->
Thanks @davidsneighbour for the suggestion, have to look at it and do some testing to see how easy/difficult this would be to implement.
Thanks @davidsneighbour for the suggestion, have to look at it and do some testing to see how easy/difficult this would be to implement.
<!-- github-comment-id:1488722794 -->
The reason you need to add path.join(__dirname, '.env') is that it would otherwise run within the extension folder.
I found a way; it was a problem in webpack, and I can make these dynamic imports work.
I think the approach will be the following:
- Adding a new setting `frontMatter.config.dynamicFilePath`
- When the setting is present, it will be loaded and used after FM processed the settings
I have done the following test:
```js
const path = require('path');
const uuid = require('uuid');
require('dotenv').config({
path: path.join(__dirname, `.env`)
});
module.exports = async (config) => {
return {
...config,
test: process.env.TESTING,
dir: __dirname,
id: uuid.v4(),
}
};
```
FM receives the config + the additional values.
<img width="1399" alt="Xnapper-2023-09-18-16 24 55" src="https://github.com/estruyf/vscode-front-matter/assets/2900833/e7971147-3dd7-43b2-b678-05f09c87d44e">
> The reason you need to add `path.join(__dirname, '.env')` is that it would otherwise run within the extension folder.
<!-- github-comment-id:1723534637 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This would be a "nice to have" feature. Enabling us to have some Javascript create a configuration object that is then exported.
Use case: My local development server (preview server) has changing IP addresses and ports depending on the machine they run on. Having IP and port configuration in
.envand then the javascript retrieve that via dotenv to create"frontMatter.preview.host": "http://192.168.1.201:1313"would increase the portability of the configuration.Something like this:
I am not sure in how far this breaks the concept of extensions inside
.frontmatterfolders, but this would be only for the frontmatter.json file in the root of the project.Thanks @davidsneighbour for the suggestion, have to look at it and do some testing to see how easy/difficult this would be to implement.
@davidsneighbour, I have been thinking of it but haven't found a way yet to make it work.
I found a way; it was a problem in webpack, and I can make these dynamic imports work.
I think the approach will be the following:
frontMatter.config.dynamicFilePathI have done the following test:
FM receives the config + the additional values.
You'll be able to test it out in the upcoming beta.