I'm searching of 'env' concept at static build file in Next.js but can't understand what is "inlining" meaning in this context. Could someone give me more specific example?
This loads process.env.NEXT_PUBLIC_ANALYTICS_ID into the Node.js environment automatically, allowing you to use it anywhere in your code. The value will be inlined into JavaScript sent to the browser because of the NEXT_PUBLIC_ prefix. This inlining occurs at build time, so your various NEXT_PUBLIC_ envs need to be set when the project is built.
https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables-to-the-browser
It means that when the build tool generates the source code to send to the browser, it will replace the instruction to read an an environment variable with a string representing the value of that environment variable at the time the build happened.
Related
Firstly: The "official" (?) node.js externs are located here: https://github.com/google/closure-compiler/tree/master/contrib/nodejs
But i can't use it because the high amount of warnings (and errors sometimes) that are generated. For example: The declaration of "process" module is very "thin"; Only has one property defined on his prototype, besides not inherit from EventEmitter, so i can't register callback when, for example, i want to do a clean job on process SIGINT (process.on('SIGINT', callback)).
When i mix several externs files declaring the core modules of node.js, more and more warnings and errors are raised (i always respect the deps tree between externs). For example: If i include the events.js and stream.js externs files, an error is raised because the "event" global var is redeclared: Once in events and again in stream.
So: What am i doing wrong?
The closure compiler that i am using is the latest git, whit --new_type_inf and --env flags activated, among others.
For example: If i include the events.js and stream.js externs files, an error is raised because the "event" global var is redeclared: Once in events and again in stream.
This highlights the core of the problem - and why they are not well maintained. The compiler doesn't recognize that these variables are in fact NOT global. The compiler currently does not have a method to correctly interpret externs as modules. The were originally contributed and consumed by a fork of the project that could understand externs as modules.
I am currently working on adding support to the compiler for this and hope to some day soon be able to completely rewrite this answer.
In the mean time, you might be able to work around some of this by adding #suppress {duplicate} annotations to the files. However keep in mind that they will still be global types.
If you wish to improve the files (like having process properly extend EventEmitter), I will happily review pull requests for such changes.
I am trying to run a silent installation of an application using Installanywhere's silent install and response file functions. I have recorded a response file multiple times, and then run a silent install using that response file, yet certain properties are not used. The target directory always ends up being correct, but things like a passphrase or a server port are completely ignored. I have researched the vendor's boards and found nothing helpful on the topic. Can anyone with Installanywhere experience be of assistance?
If those panels are custom, it is a vendor bug: storing variable to response file is an additional action that should be added to custom panel code
it is possible though to investigate the installer and find out what variable to add to response file
The problem might be that the installer you are using relies on "merge modules". It seems that variable values are not passed to-and-from merge modules when running in silent mode.
I have unfortunately encountered this issue with the installers I'm working on, but the Flexera forums don't provide much help either:
silent installation with merge modules
merge module variable are accessible in silent install
The vendor may not even be aware of this either.
Just put to blank your default value in your "Set installanywhere variable"'s action, Otherwise values from your properties file (for silent install) will be overwrite by values define in action 'Set installAnywhere variable".
As stated in Flexera's documentation, you will need to set the variable both in your proxy's 'setVariable' method, and ReplayService 'register' method.
The 'register' method is responsible on writing the variable to the response file:
customCodePanelProxy.setVariable("MY_VAR", "MY_VALUE");
ReplayVariableService replayService = (ReplayVariableService)customCodePanelProxy.getService(ReplayVariableService.class);
// This will do the trick:
replayService.register("MY_VAR", "MY_VALUE");
For further details refer to this IA guide:
http://helpnet.flexerasoftware.com/InstallAnywhereAPI/IA2010/javadoc/com/zerog/ia/api/pub/ReplayVariableService.html
I usually follow the unofficial Meteor FAQ on how to structure my codebase, but I can't figure out where I should put my global constants.
To give an example: I have some database entries with a constant GUID that I need to reference in many points of my app. So far I just attached the constants to the relevant collection, such that in collections/myCollectionWithGuids.coffee it would say:
#MyCollectionWithGuids = new Meteor.Collection "myCollectionWithGuids"
#MyCollectionWithGuids.CONSTANT_ID = "8e7c2fe3-6644-42ea-b114-df8c5211b842"
This approach worked fine, until I need to use it in the following snippet, located in client/views/myCollectionWithGuidsView.coffee, where it says:
Session.setDefault "selectedOption", MyCollectionWithGuids.CONSTANT_ID
...which is unavailable because the file is being loaded before the Collections are created.
So where should I put my constants then, such that they are always loaded first without hacking in a bunch of subdirectories?
You could rely on the fact that a directory names lib is always treated first when it comes to load order.
So I would probably advise you to organize your code as follow :
lib/collections/collection.js
client/views/view.js
In your particular use case this is going to be okay, but you might find cases when you have to use lib in your client directory as well and as the load order rules stack (subdirectories being loaded first), it will be loaded BEFORE the lib folder residing in your project root.
For the moment, the only way to have full control over the load order is to rely on the package API, so you would have to make your piece of code a local package of your app (living in the packages directory of your project root).
It makes sense because you seem to have a collection and a view somehow related, plus splicing your project into a bunch of collaborative local packages tends to be an elegant design pattern after all.
Creating a local package is really easy now that Meteor 0.9 provide documentation for the package.js API.
http://docs.meteor.com/#packagejs
I would put your collection definitions in a lib directory. File structure documentation explains that all files under the lib directory get loaded before any other files, which means your variable would be defined when you attempt to access it in your client-side code.
Generally speaking, you always want your collections to be defined before anything else in your application is loaded or executed, since your application will most likely heavily depend upon the use of the collection's cursor.
Given a build.sbt which is committed to a code repository, what is a general pattern which allows users to override setting values defined in this script?
On the surface, this appears to have been answered in Where should local settings (per user, and not version-controlled) go in newer (0.10+) versions of SBT?. The answer there is to simply define two scripts in the same directory -- build.sbt and local.sbt, and rely on the fact that sbt will combine these scripts together. This may work for augmenting values (i.e., appending lists), but I don't see how it works for overriding the script value, since if a setting's value is set in both scripts, I don't know which of the two values will survive after sbt has combined the scripts.
It could be that I'm missing something very simple.
I'd recommend using ~/.sbt/0.13 global directory where your .sbt files are processed during project load and after the other files in the project itself.
I found ~/.sbt/0.13/global.sbt a good place for global settings - the name always hints me for its purpose.
in my project, I want to refer to an other xcconfig file, located in InDesign SDK. As this SDK may be installed at different locations, depending upon the machine, I prefer to declare an environment variable for locating it.
Nest step is obviously to use variable (aptly named ID_CS5_SDK_DIR) in my xcconfig include directive.
Unfortunatly, when I try the simple
// InDesign sdk project build settings (based on common build settings)
#include "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
XCode throws me a
[WARN]AutocatPlugin.xcconfig line 7: Unable to find included file "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
How can I make it work ?
I've been trying to do this too and also came to the conclusion that it is not possible.
I once tried to achieve that and came to the conclusion that you can't. I would be happy if someone proves us it's possible though then delete my answer
It seems like .xcconfig files can only DEFINE and set value to environment variables (which prevail only throughout the build session) but not USE or evaluate environment variables.
Maybe it is because .xcconfig files serve as a base layer of build-settings, and are not parsed.
Unfortunately this is not possible, but instead of making one include the other, you can use two different xcconfig files per target. Just select one for the Project and one for the Target.
If you put the environment variable in /etc/config/launchd.conf and then reboot it will be accessible to the .xcconfig file.
Short Instructions for experienced users:
Edit the read-only file /etc/launchd.conf and add 'setenv VARIABLENAME /FOLDER/PATH' to the file, then reboot.
Steps For Inexperienced Users
Open Application/Utilities/Terminal, and entersudo nano /etc/launchd.conf
Create the Environment Variable by adding a line like setenv VARIABLENAME FOLDER/PATH and then pressing ENTER.
Save the file using Ctrl-O, Ctrl-M, (Possibly Ctrl-Y to overwrite), then Ctrl-X to exit the editor.
(Optional) type cat /etc/launchd.conf to see that your changes are present
Restart your computer. (Logoff doesn't work)
You can now access the variable in your .xcconfig file as$(VARIABLENAME)
Notes:
This creates a GLOBAL environment variable, accessible to all users. It probably doesn't make sense to set this to something in your home directory (e.g ~/MyFolder). If you do this, however, you need to use the full pathname, such as /Users/MyUserName/MyFolder).
References:
Stack Overflow - Setting Environment Variables in OSX
Stack Overflow - Are there any differences between /etc and /private /etc