-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
add new env vars MM_MODULES_DIR and MM_CUSTOMCSS_FILE … #3530
Conversation
hm. this will break modules which depend on their location being two directories up from the root and others that depend on folder names. will also break my upgrade script what will be the effect on git pull if the deployed structure is different? |
the idea would be
So can you explain what exactly would break?
# Ignore users config file but keep the sample.
/config/*
!/config/config.js.sample no effect because above is in |
you can already now change the |
can either/both of these be outside the MagicMirror folder tree? |
I did not test this so far, will do and report. I think at least |
both variables (or corresponding values in let directories = ["/config", "/css", "/fonts", "/modules", "/vendor", "/translations", "/env"]; |
ok, so one could set modules to config, but not new dir foo, same for config to modules, but not foo and does it require leading slash? |
yes.
no. You can define it like node@81ac3b4687ab:/opt/magic_mirror$ export MM_CUSTOMCSS_FILE=config/custom.css
node@81ac3b4687ab:/opt/magic_mirror$ export MM_CUSTOMCSS_FILE=/config/custom.css
node@81ac3b4687ab:/opt/magic_mirror$ export MM_CUSTOMCSS_FILE=/opt/magic_mirror/config/custom.css All 3 variants works, the mm root dir is stripped in the code. |
ok, can cssfile be modules/foo.css i misread cssfile, thinking config file and folder could be moved |
i always assumed cssfile was name of file, not location |
The default |
thanks, i never thought one could change the css directory, only the filename |
I haven't checked the code yet, in all cases at the time a module is loaded are the config variables set so I can use those as the true path? vs examining for the env myself.. |
in MMM-Config I launch a shell script to collect all the module defaults and generate the form object.. |
at the moment this is still unmerged ...
The new variables don't touch
const res = await fetch(`${location.protocol}//${location.host}/env`);
return JSON.parse(await res.text());
this is unrelated to this PR but you should check |
the config object after parsing is available to the browser sideof the module, so I could see the config.modules.path I was just wondering if you used the env to update that (as your PR comments say 'override' ) I don't really need the config object, and I don't care about css really. |
thanks, didn't thought about this, but I think it would be the better way to change the values in the config object. Will check this and change it if it works. |
the config object is available to the browser because of these lines in <script type="text/javascript" src="js/defaults.js"></script>
<script type="text/javascript" src="#CONFIG_FILE#"></script> (the So I stay with the current approach because otherwise I had to manipulate content of |
understood. i forgot they are loaded from file |
@rejas from my side this is ready for review |
no but there was a bug in the code so this couldn't work (because So what are you testing?
|
testing 2.29 prior to this PR..
so, YES, you had to change something to get this PR to work . the original code was broken trying to test setting modules location thru config.js, before env variable.. |
line 162 in let moduleFolder = `${__dirname}/../modules/${module}`; was not using |
ok, two things
|
well, I don't know exactly what you tested, AFAIS you are not testing this PR (the new env vars) but the config.js functionality (which was already there before this PR).
yes, had this problem too, you must provide a full object under Let me know if I should update this PR with such a fix.
sorry, don't understand/don't know what you expect from me here |
altho.. I am sure that on all file systems we run on, there is a link capacbility for those that want to move things around physically without us having to provide config options.. |
@sdetweil fixed the things you mentioned above. Tests are failing at the moment unrelated to this PR (did the tests on |
crazy that we get these random failures... |
the basic idea is to use one dir ( |
windows 11 has symlinks |
looks good both env and config parm |
b8c1a02
to
af1d732
Compare
…se things from outside (and overriding corresponding config.js properties)
…onfig.foreignModulesDir`
af1d732
to
3016cef
Compare
I have tested it extensively, and I think it works well.. so yes, you can merge |
uses newsfeed test after copying this module to config dir addition for #3530
## [2.29.0] - 2024-10-01 Thanks to: @bugsounet, @dkallen78, @jargordon, @khassel, @KristjanESPERANTO, @MarcLandis, @rejas, @ryan-d-williams, @sdetweil, @skpanagiotis. >⚠️ This release needs nodejs version `v20` or `v22`, minimum version is `v20.9.0` ### Added - [compliments] Added support for cron type date/time format entries mm hh DD MM dow (minutes/hours/days/months and day of week) see https://crontab.cronhub.io for construction (#3481) - [core] Check config at every start of MagicMirror² (#3450) - [core] Add spelling check (cspell): `npm run test:spelling` and handle spelling issues (#3544) - [core] removed `config.paths.vendor` (could not work because `vendor` is hardcoded in `index.html`), renamed `config.paths.modules` to `config.foreignModulesDir`, added variable `MM_CUSTOMCSS_FILE` which - if set - overrides `config.customCss`, added variable `MM_MODULES_DIR` which - if set - overrides `config.foreignModulesDir`, added test for `MM_MODULES_DIR` (#3530) - [core] elements are now removed from `index.html` when loading script or stylesheet files fails - [core] Added `MODULE_DOM_UPDATED` notification each time the DOM is re-rendered via `updateDom` (#3534) - [tests] added minimal needed node version to tests (currently v20.9.0) to avoid releases with wrong node version info - [tests] Added `node-libgpiod` library to electron-rebuild tests (#3563) ### Removed - [core] removed installer only files (#3492) - [core] removed raspberry object from systeminformation (#3505) - [linter] removed `eslint-plugin-import`, because it doesn't support ESLint v9. We will reenter it later when it does. - [tests] removed `onoff` library from electron-rebuild tests (#3563) ### Updated - [weather] Updated `apiVersion` default from 2.5 to 3.0 (#3424) - [core] Updated dependencies including stylistic-eslint - [core] nail down `node-ical` version to `0.18.0` with exception `allow-ghsas: GHSA-8hc4-vh64-cxmj` in `dep-review.yaml` (which should removed after next `node-ical` update) - [core] Updated SocketIO catch all to new API - [core] Allow custom modules positions by scanning index.html for the defined regions, instead of hard coded (PR #3518 fixes issue #3504) - [core] Detail optimizations in `config_check.js` - [core] Updated minimal needed node version in `package.json` (currently v20.9.0) (#3559) and except for v21 (no security updates) (#3561) - [linter] Switch to ESLint v9 and flat config and replace `eslint-plugin-unicorn` by `@eslint/js` - [core] fix discovering module positions twice after #3450 ### Fixed - Fixed `checks` badge in README.md - [weather] Fixed issue with the UK Met Office provider following a change in their API paths and header info. - [core] add check for node_helper loading for multiple instances of same module (#3502) - [weather] Fixed issue for respecting unit config on broadcasted notifications - [tests] Fixes calendar test by moving it from e2e to electron with fixed date (#3532) - [calendar] fixed sliceMultiDayEvents getting wrong count and displaying incorrect entries, Europe/Berlin (#3542) - [tests] ignore `js/positions.js` when linting (this file is created at runtime) - [calendar] fixed sliceMultiDayEvents showing previous day without config enabled --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Michael Teeuw <michael@xonaymedia.nl> Co-authored-by: Kristjan ESPERANTO <35647502+KristjanESPERANTO@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ross Younger <crazyscot@gmail.com> Co-authored-by: Veeck <github@veeck.de> Co-authored-by: Bugsounet - Cédric <github@bugsounet.fr> Co-authored-by: jkriegshauser <joshuakr@nvidia.com> Co-authored-by: illimarkangur <116028111+illimarkangur@users.noreply.github.com> Co-authored-by: sam detweiler <sdetweil@gmail.com> Co-authored-by: vppencilsharpener <tim.pray@gmail.com> Co-authored-by: veeck <michael.veeck@nebenan.de> Co-authored-by: Paranoid93 <6515818+Paranoid93@users.noreply.github.com> Co-authored-by: Brian O'Connor <btoconnor@users.noreply.github.com> Co-authored-by: WallysWellies <59727507+WallysWellies@users.noreply.github.com> Co-authored-by: Jason Stieber <jrstieber@gmail.com> Co-authored-by: jargordon <50050429+jargordon@users.noreply.github.com> Co-authored-by: Daniel <32464403+dkallen78@users.noreply.github.com> Co-authored-by: Ryan Williams <65094007+ryan-d-williams@users.noreply.github.com> Co-authored-by: Panagiotis Skias <panagiotis.skias@gmail.com> Co-authored-by: Marc Landis <dirk.rettschlag@gmail.com>
… for setting these things from outside (and overriding corresponding config.js properties
config.foreignModulesDir
andcustomCss
)config.paths.vendor
(could never work becausevendor
is hardcoded inindex.html
) and renamedconfig.paths.modules
toconfig.foreignModulesDir
. Theconfig.paths. ...
properties were implemented in the initial commit injs/defaults.js
but were never functional.app.js
which didn't respectconfig.paths.modules
beforemodules/defaults
is directly set in many places in the source code restrictconfig.paths.modules
to foreign modules (it has never worked for default modules), now renamed toconfig.foreignModulesDir
/env
section inserver.js
for getting the new env vars in the browserserver.js
so test directories are now only published when running testsThese changes allow changing some main paths from outside mm with the new env vars. You now can put all user stuff into one directory, e.g. the
config
dir:config.js
as beforecustom.css
This would simplify other setups e.g. the docker setup. At the moment we have to deal with 3 directories where 2 of them (
modules
andcss
) contains mixed stuff, which means mm owned files and user files. This can now simplified and leads to cleaner setups (if wanted).