This allows you to modify response headers or bodies, or bypass SvelteKit entirely

import '@sveltejs/kit/install-fetch';

Adapters are required to make Request globally available if it isn't already part of the target platform. It's part of the (currently undocumented) contract — see e.g. adapter-node

for internal case you can have endpoint call instead true request. Basically, it's has sense only for external API.

CSR asking my Python backed directly (over nginx). Basically, in my particular situation, I want to use most shorter paths for SSR or CSR cases when I have a separate API server under the same domain and nginx frontend.

on CSR it connects to the svelte-kit endpoint which just use a localhost connection. and to optimize this you can use unix sockets in your endpoints to connect to backend server

I don't want to use an extra proxy, it's the wrong architecture design that killed performance.

ah you are talking about a external api endpoint server? then you could use the svelte-kit endpoints as proxy handler

I want to avoid nginx overhead (especially if they have tons of alias and rewrites) for in-server communication. Basically, you can have sveltekit server, backend server and nginx server, in that case, communicate inside your internal network will be very expensive like: browser->nginx server(10.0.0.1)->sveltekit server(10.0.0.3)->nginx server(10.0.0.1)->backend server(10.0.0.2) instead just: browser->nginx server(10.0.0.1)->sveltekit server(10.0.0.3)->backend server(10.0.0.2)

(name subject to bikeshedding)

We certainly wouldn't want to add non-standard appendages to the fetch API, partly because it's confusing but mostly because it would be repetitious; you would need to include that logic in every load function that used the API in question.

Stay engaged. As mentioned above, you are expected to check your GVSU email twice daily, read new posts on CampusWire twice daily, contribute to the discussion board daily, and make at least two significant contributions to CampusWire per week. Make daily engagement with the course a habit, and don’t take days off (unless it’s a weekend and you have all your work done).

Budget your time. MTH 124 is a 5-credit course with no meetings, so you will need to plan on spending about 15-20 hours per week doing mindful work. That’s 3-4 hours per weekday if you choose not to work on weekends. If you are taking other courses or have job of family responsibilities, you’ll need to think about where to put these hours in your daily and weekly schedules. In my experience, the #1 reason students don’t succeed in online courses is overcommitment and not managing time well.

First of all, I would start off presenting yourself: Dear XYZ support team I am the web developer in charge of example.com website. By presenting you this way, you are establishing the frame to treat you, hinting that you should be presupposed to be somewhat proficient, so they could choose to answer in a more technical detail.

Consider that many customers are rude or arrogant, so you can safely brag a little and still come off as comparatively wonderful! Help them help you with that short brag and they'll only be appreciative. And remember: be nice and it's ok to lose the modesty for a sentence or two! Source: I'm a CS rep at a tech company, and I appreciate it when savvy customers clue me into it!

No need to apologize. The bold "be nice" and 'limit your bragging to a sentence or two' clarifies your tone perfectly

Feel free to hint, brag, or both! The best CS reps should easily take a hint from clear language and a signature like John Appleseed, JavaScript/Ruby Developer, but any will catch on with a simple line like "I know what I'm doing, so I'd appreciate an extra-technical explanation!"

any will catch on with a simple line like "I know what I'm doing, so I'd appreciate an extra-technical explanation!"

One solution that fixed this issue with my ISP was that when I went through the first and second line and got in touch with the people that fixed my problem, I asked them if they could give me one of their personal numbers in case the same problem happened again. The problem did occur a couple more times, and I just directly called the same guy.

If you're already an admin for the zone in question, then the proper way to get that information is to log on to the DNS server or DNS control console and read it right from there. If you're not an admin for the zone, you're not supposed to have that information. Note that the person you are talking to on the phone is almost certainly not a DNS zone admin, so they also should not have that information. If they somehow did have it, they definitely shouldn't give it out over the phone. This is for your protection.

DNS zone information is sensitive. Many years ago it was possible for anyone to query a DNS server and literally get back all the records at once, but that was a security issue. Now you have to be an admin for the zone to get that info.

One way to look at your current situation is that you're not paying them enough to tell you the gory details, not that you're not knowledgeable enough.

If the hosting company (or any organization that you're trying to get support from) wanted you to know something, they would have already told you or made that information available.

If you choose to say 'I already told you that' {4} then your tone of voice is critical. If you say the above in a snarky/belittling tone the rep isn't going to want to help you. And that does matter. Smile between each response - especially if you are tired or annoyed.

Hey, I'm a PhD in [field] and do [whatever] professionally. Before calling you, I've narrowed down the problem to [something on their end], so that's what needs to be addressed. If I could speak to an engineer about [specific problem], that'd be great; but if we've gotta walk through the script, let's just knock it out quickly. If they end up requiring the script, then the best way to use your expertise is to run through it quickly. Keep the chit-chat to a minimum and just do the stuff efficiently. If they start describing how to perform some step, you might interrupt them with, "Got it, just a sec.", then let them know once you're ready for the next step.

With experience you would get to have an idea about how knowledgeable the customer was just by talking to them for a few seconds, but you have to be careful not to assume things.

Nowadays when I want technical support I will email my web host and give them all the necessary information, i.e. what I have tried to do to resolve, what I think the problem is etc and usually it is fixed first time within a few hours. If I need urgent assistance I will ring them but 99% of the time email is sufficient and less stressful, rarely do I need to send a second email.

Companies do tend to use scripts but the good ones will allow their staff to stray off the script once they are experienced enough to do so as long as it benefits the customer and the company, usually this involves fixing the problem more quickly.

My advice is if you are looking for a quick and accurate answer ask to have the trouble ticket elevated immediately and to speak with an engineer that will recognize your knowledge and speak with you on your level.

Stack-exchange is not teaching or education. It's just giving out answers for upvotes. Just like some tech support is about closing tickets.

Some people, regardless of their experience level are horrible as teachers. A school teacher gets asked the same question every year. Every year they answer them, even if it seems redundant, and the answers are simple to THEM. Teaching requires patience and the acceptance of being asked "dumb questions" repeatedly. If they cannot handle that, then they should simply not teach or pretend to be a teacher.

You must understand that tech support constantly gets bombarded by calls from people who refuse to learn or accept genuine solutions.

Furthermore many of them are paid or rated by the number of tickets they close, not solutions. It's a bad recipe and unfortunately it has become the norm.

I typically request to speak with an engineer when I find myself detecting an inexperienced support person.

I find most tech support is filled with inexperienced and frustrated staff who just run off a script. They're not paid well. They are Tier One support to filter out most of the incoming calls. Tech support is designed in tiers.

However, what speaks against just straight up telling them that you're working as [Insert title of your position] and you know what you're talking about?

tweet at them. This has multiple effects: If they don't respond, it's bad PR

And asking them if they think they know what they are doing will not help, because many people will overestimate their knowledge, making the support even more complicated as the tech guy may at first believe them and only find out later that they told wrong things because they do not actually know what they are pretending to know.

Of course, if you're too successful with migrating all your clients and friends to your friendly small provider it grows into a big provider and needs to hire cheap first level support to deal with all the customers ;-)

Heisenberg for customer support quality ;-)

The best advice I can give you is: Seek a smaller provider which often are less formal and more approachable. When you found one where you have a good support, request your friends and family to move to this. You are doing something for them, then it can only happen on your terms.

If the person answering the call misses something, nothing prevents them from asking you to repeat something. I think the key point that should be added to this answer is to not sound or act annoyed if the support tech asks for something you've already rattled off. To accept that you gave them a whole bunch of information at once, and that they might legitimately have missed or forgot one bit of it. Or, especially if you know the order in which they ask these questions, to take it slower; don't say it all in five seconds, take half a minute. Give them time to click!

Tech support works with scripts. Just get to know these scripts by heart and answer all questions from the script you can in one long sentence, before they ask it. Like in "Hi I have a problem with this and that...I have restarted the router, I have checked the cables, the red light is on, the green light is off, not other lights are blinking......etc.etc.etc. That way the person at the other end of the line can just go click-click-click and you'll be 10 steps further in their script in 5 seconds.

So what can you do to demonstrate your technical knowledge? Well, you are doing the right thing by using the correct technical terms. That will give an indication to the person handling the ticket. Explicitly explaining your role as the administrator or developer should also help.

From experience I can say that professionals will be more forgiving if you go through things at a basic level than amateurs who have no idea what you're talking about, so people will probably err on the side of caution and not assume the customer has a high level of expertise.

"Put as much information about the problem itself into the email". This is where you show your ability to know what is important and relevant and establish your technical level. Don't be brief, don't imply, and break it down Barney style so the person receiving it knows to escalate your ticket.

Look for certain questions that have been asked every time, and put those answers into the initial email you send about the new problem. Try to add things that make the potential problem sound local. The more information you give them that you know they will be asking for in their script, the faster you will get someone who can help you. And they will thank you for it.

If you email helpdesk (us specifically), if you use appropriate technical detail you will probably get someone who knows what they're doing, and will greatly appreciate it. If you call, you will get me only. I will ask you lots of questions, with awkward pauses in between while I write my notes, and at the end of it I probably won't be able to help you. Technical detail is still welcome, but there are some questions I will ask you anyway even if they sound useless to you

Put as much information about the problem itself into the email, within reason. No need to write a paragraph, that takes time away from you and from us. Bullet points are perfect (preferred).

And if your answers tell me it's something too advanced for me, only then would I escalate it.

e-mailing

Calling over e-mailing has a number of advantages, you're able to empathize with the person and they're able to hear how comfortable you are with the topic over the phone.

because you display knowledge of the field naturally and you also show them you know how system administration in general works

So, +1 for play ball. Level 1 is supposed to filter out all simple issues (and once upon a time, you'll have forgotten something, happens to all of us), and they are not supposed to be creative. They get a script that has been refined over and over. Learn the scripts, prepare the answers, and you'll get to Level 2 more quickly than with any other method.

In one of my internship, I got to befriend a level 2 tech support, so learned a couple thing of how it worked (in that company). Level 1 was out-sourced, and they had a script to go from, regularly updated. From statistics, this took care of 90% of issues. Level 2 was a double handful of tech people, they had basic troubleshooting tools and knowledge and would solve 90% of the remaining issues. Level 3 was the engineering department (where I was), and as a result of level 1 and 2 efficiency less than 1% of issues ever got escalated. The process worked!

OP is referring to letting people know they can speak like proper adults when talking about technical terms, without going through the usual nanny-like discourse that tech support has to provide to non-techies. For instance, it happened to me with Amazon support. The speaker told me exactly where to touch in order to clear the cache of the Android Amazon App Store. Given that I work as an app developer the guy could have just said "please clear the cache". No need to go through "tap here, then here, now you should see this, tap that"...

the problem is that I write a lot of these emails and they are a waste of my and everyone elses time

Please don't write answers in comments; we have a policy against this. If you have an answer to the question, write it up as an answer. Thanks.

If possible I'd like to avoid writing my academic and professional titles in my email signature as this might be seen as "showing off".

I have tried different tactics of showing the tech support that I am proficient in their field of work (I work as a web developer). Specifically: using accurate terms and technologies to show my knowledge of them and telling the support that I am the "administrator" of the website in question.

How to let tech support subtly know that I am proficient without showing off?

Unfortunately the tech support people you are speaking to are probably as frustrated as you are at having to go through the basic stuff with you.

Large companies especially deal with the massive volume of tech support calls they receive by employing some staff on lower pay as a "buffer," dealing with simple or "known" issues so that they don't need to employ as many higher paid "second line" support staff.

Very often the first people you get through to on tech support lines are reading from a script.

They have to ask you the dumb questions, either because their employer demands they do, or sometimes because their computer system doesn't let them get to the next part of the script unless they play ball.

Which is not to say that people employed on first line support are not knowledgeable; in my experience lots of over-qualified people have to take less advanced jobs in IT just to get into the industry.

Another will employ smart people who apologise to you profusely for having to go through all the pointless steps, but that's just what they have to do!

However I appreciate that price and functionality often dictates who we deal with.

So my best advice if you need to stick with them is just to expect the treatment you have become used to and 'play along'. Actually, I find some things often run smoother when you act dumber than you are.

Historically, the uncertainty principle has been confused[5][6] with a related effect in physics, called the observer effect, which notes that measurements of certain systems cannot be made without affecting the system, that is, without changing something in a system.

the uncertainty principle actually states a fundamental property of quantum systems and is not a statement about the observational success of current technology.

Such variable pairs are known as complementary variables or canonically conjugate variables

I would argue though that crashing is better than quietly providing unexpected behavior.

Non-solutions Start replacing process.env[ with ({})[ if you're sadistic

Currently people are working around this using process.env['SECRET'] to avoid the string replacement

This looks cool but right now, let's say i have an external api which depends on users cookies, the cookies only gets send through internal sk endpoints while ssr even if its the same domain. Couldn't we pass the 'server' request to the serverFetch hook? I would currently have to patch package svelte kit to pass request headers to the external api or create an sk endpoint which proxies the request.

also it's can be helpful for geo deploying when your browser should get access to closest API by GeoDNS but server part can touch neighborhood server or same server.

Skirmish mode, where the original game did great, this version lacks a bit of content. For instance, in the original game you could give your CPU (AI) players a name, so you could for instance relive the Avernii vs the XII Legion or anything for that matter. In the remasterd version you can't name any CPU players, which in my opinion is a loss. A lot of the skirmish fun was with the immersion of the factions.

Due to the cost and complexity of VAT/GST, Frozen Soul Games won't be able to register within each country. VAT/GST will be due upon pick-up after we ship to you. Thank you for your understanding.

Unfortunately one can only buy the standard or the soundtrack version, without any chance to upgrade, to buy the DLC extra. In this case I can only say if you get the game on a good sale (75 percent or more) and collect music, or if you want to support the developer, you might want the soundtrack edition.

I cherry-picked the first commit into #872, we can add .erb support later if we find we need it.

Although I don't use it much, I certainly don't plan to break it!

Because constants in Ruby aren't meant to be changed, Ruby discourages you from assigning to them in parts of code which might get executed more than once, such as inside methods.

It doesn't say that the constant is dynamic. It says that the assignment is dynamic.

git diff --relative will print paths from the dir you are in.

I've been using (and recently, contributing slightly to) Git for well over a decade. I don't have any single thing I'd specifically recommend at this point, but if you're looking for a decent book on Git, the Pro Git book has a bunch of plus-es: it's on line and kept up to date, it's free, and it's correct (unlike far too many online tutorials). There is also Think Like (a) Git, which covers most of what's missing from Pro Git.

$ ed - var.c << end > 0a > xxx > . > wq > end

If you would like to make a code change, go ahead. Fork the repository, open a pull request. Do this early, and talk about the change you want to make. Maybe we can work together on it.

Local development and testing has huge advantages, but sometimes one needs to test web applications against their real-world domain name. Editing /etc/hosts is a pain however, and error prone. Node Foreman can start up an HTTP forward proxy which your browser can route requests through. The forward proxy will intercept requests based on domain name, and route them to the local application.

For users with Google Chrome, this can be paired with FelisCatus SwitchyOmega for great results.

nf start -j Procfile.dev

this is incomplete. Yes you get a load of commits, but they no longer refer to the right paths. git log dir-B/somefile won't show anything except the one merge. See Greg Hewgill's answer references this important issue.

kdiff3 can be used solely with keyboard, so 5 conflict file takes when reading the code just few minutes.

If you're wondering, to insert a <tab> in osx, you need to Ctrl-V <tab>

I think so...I actually can't remember. I've used this script quite a bit.

Thanks. Worked for me. I needed to move the merged directory into a sub-folder so after following the above steps I simply used git mv source-dir/ dest/new-source-dir

In case you want to put project-a into a subdirectory, you can use git-filter-repo (filter-branch is discouraged)

Note: This rewrites history;

Shorter: git fetch /path/to/project-a master; git merge --allow-unrelated-histories FETCH_HEAD.

--ignore-unmatch

https://github.com/reaxis/mu µ

Are you also tired and fed up with the bulkiness of jQuery, but also don't want to have to type document.querySelector("div").appendChild(document.createTextNode("hello")); just to add some text to an element?

µ

Before we dive into the details of the actual migration, let’s discuss the theory behind it.

Seamless transitions; changes made to the old repositories after they were migrated must be imported to the new monorepository.

Preserving history; we often find ourselves using the git blame tool to discover why a certain change was made.

Our requirements:

A transition period rather than Stop-The-World migration; we want to merge in a few repositories per day, with minimal disruption to work-flow.

The implicit dependencies between different versions of different services were not expressed anywhere, which led to various problems in building, continuous integration, and, notably, repeatable builds.

Preserving commit hashes; we use commit hashes in binary names and our issue tracker; ideally, these references remain intact.

You may want to try putting the one-liner (everything in the single quotes) in an actual script, with a bash shebang line. I think filter-branch is probably trying to run this in sh, not bash.

If you want the project's history to look as though all files have always been in the directory foo/bar, then you need to do a little surgery. Use git filter-branch with the "tree filter" to rewrite the commits so that anywhere foo/bar doesn't exist, it is created and all files are moved to it:

git push -b

       git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
                  [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
                  [-u | --set-upstream] [-o <string> | --push-option=<string>]
                  [--[no-]signed|--signed=(true|false|if-asked)]
                  [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
                  [--no-verify] [<repository> [<refspec>...]]

New changes to the old repositories can be imported into the monorepo and merged in. For example, in the above example, say repository one had a branch my_branch which continued to be developed after the migration. To pull those changes in:

Don't Stop The World: keep working in your other repositories during the migration and pull the changes into the monorepo as you go.

Maybe the source code was originally thought to be independent but was later discovered to be “rightly coupled”.

#blogumentation

For filter-branch, using pipelines like git ls-files | grep -v ... | xargs -r git rm might be a reasonable workaround but can get unwieldy and isn't as straightforward for users; plus those commands are often operating-system specific (can you spot the GNUism in the snippet I provided?)

None of the existing repository filtering tools did what I wanted; they all came up short for my needs. No tool provided any of the first eight traits below I wanted, and all failed to provide at least one of the last four traits as well:

[Old commit references] Provide a way for users to use old commit IDs with the new repository (in particular via mapping from old to new hashes with refs/replace/ references).

a cheat sheet is available showing how to convert example commands from the manual of filter-branch into filter-repo commands.

die-hard fans of filter-branch may be interested in filter-lamely (a.k.a. filter-branch-ish), a reimplementation of filter-branch based on filter-repo which is more performant

Let's say that we want to extract a piece of a repository, with the intent on merging just that piece into some other bigger repo.

--tag-rename '':'my-module-' (the single quotes are unnecessary, but make it clearer to a human that we are replacing the empty string as a prefix with my-module-)

It would be unfortunate for the "LTS" kernel version to not be installable on LTS Ubuntu.

Also, it is definitely NOT okay to recommend --force on forums, Q&A sites, or in emails to other users without first carefully explaining that --force means putting your repositories’ data at risk. I am especially bothered by people who suggest the flag when it clearly is NOT needed; they are needlessly putting other peoples' data at risk.

These checks can have both false positives and false negatives.

The .git/filter-repo/ref-map file contains a mapping of which local references were changed.

Every time filter-repo is run, files are created in the .git/filter-repo/ directory. These files overwritten unconditionally on every run.

The .git/filter-repo/commit-map file contains a mapping of how all commits were (or were not) changed.

However, the place where pip places that package might not be in your $PATH (thus requiring you to manually update your $PATH afterwards), and on windows the pip install might not take care of python-specific issues for you (see "Notes for Windows Users", above). As such, installation via package managers is recommended instead.

If your python3 executable is named "python" instead of "python3" (this particularly appears to affect a number of Windows users), then you'll also need to modify the first line of git-filter-repo to replace "python3" with "python".

one of the following package repositories:

Installation via Package Manager

the bullet-proof way to add a path (e.g., ~/opt/bin) to the PATH environment variable is PATH="${PATH:+${PATH}:}~/opt/bin"

even if system scripts do not use this (I wonder why)

Thank you for this answer, perfectly detailed.

They also let us make assumptions about relative relationships between folders during development.

Monorepos let us version our back-end with our front-end, making compability easy with combined builds and deployments using a shared CI/CD pipeline.

By default, groups created in: GitLab 12.2 or later allow both Owners and Maintainers to create subgroups. GitLab 12.1 or earlier only allow Owners to create subgroups.

Make it easier to manage people and control visibility. Give people different permissions depending on their group membership.

Organize large projects. For large projects, subgroups makes it potentially easier to separate permissions on parts of the source code.

Allowing users to use the bulk of your service without receiving cookies.

the majority of XSS attacks target theft of session cookies. A server could help mitigate this issue by setting the HttpOnly flag on a cookie it creates, indicating the cookie should not be accessible on the client.

Cross-site scripting (XSS) vulnerabilities (even in other applications running on the same domain) allow attackers to bypass essentially all CSRF preventions.

The NoScript extension for Firefox mitigates CSRF threats by distinguishing trusted from untrusted sites, and removing authentication & payloads from POST requests sent by untrusted sites to trusted ones. The Application Boundary Enforcer module in NoScript also blocks requests sent from internet pages to local sites (e.g. localhost), preventing CSRF attacks on local services (such as uTorrent) or routers.

The Self Destructing Cookies extension for Firefox does not directly protect from CSRF, but can reduce the attack window, by deleting cookies as soon as they are no longer associated with an open tab.

The advantage of this technique over the Synchronizer pattern is that the token does not need to be stored on the server.

The same-origin policy prevents an attacker from reading or setting cookies on the target domain, so they cannot put a valid token in their crafted form.

Security of this technique is based on the assumption that only JavaScript running on the client side of an HTTPS connection to the server that initially set the cookie will be able to read the cookie's value.

As the token is unique and unpredictable, it also enforces proper sequence of events (e.g. screen 1, then 2, then 3) which raises usability problem (e.g. user opens multiple tabs). It can be relaxed by using per session CSRF token instead of per request CSRF token.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Attacks were launched by placing malicious, automatic-action HTML image elements on forums and email spam, so that browsers visiting these pages would open them automatically, without much user action. People running vulnerable uTorrent version at the same time as opening these pages were susceptible to the attack.

Details were not released, citing "obvious security reasons".

Cross-site request forgery is an example of a confused deputy attack against a web browser because the web browser is tricked into submitting a forged request by a less privileged attacker.

This link may be placed in such a way that it is not even necessary for the victim to click the link. For example, it may be embedded within an html image tag on an email sent to the victim which will automatically be loaded when the victim opens their email.

A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action.

Data tainting[edit] Netscape Navigator briefly contained a taint checking feature. The feature was experimentally introduced in 1997 as part of Netscape 3.[10] The feature was turned off by default, but if enabled by a user it would allow websites to attempt to read JavaScript properties of windows and frames belonging to a different domain. The browser would then ask the user whether to permit the access in question.

This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies[1] to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client-side to prevent the loss of data confidentiality or integrity.

Cross-site scripting attacks are a case of code injection.

A reflected attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim's browser to execute the injected script.

By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user.

Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system.

Any code designed to do more than spread the worm is typically referred to as the "payload".

Please you please cc when you create that issue. It will probably help me reproduce with rollup too.

How do I setup a path alias? permalink First, you need to add it to the Vite configuration. In svelte.config.js add vite.resolve.alias: // svelte.config.js import path from 'path'; export default { kit: { vite: { resolve: { alias: { $utils: path.resolve('./src/utils') } } } } }; Then, to make TypeScript aware of the alias, add it to tsconfig.json (for TypeScript users) or jsconfig.json: { "compilerOptions": { "paths": { "$utils/*": ["src/utils/*"] } } }

How do I hash asset file names for caching? permalink You can have Vite process your assets by importing them as shown below: <script> import imageSrc from '$lib/assets/image.png'; </script> <img src="{imageSrc}" />

noReload Type: bool Default: false

noPreserveState Deprecated: removed and default changed from version 0.12. Use preserveLocalState instead.

most of my 1K+ packages

There are two ways to move your packages to ESM:Pure ESMThis has the benefit that it’s easier to set up. You just add "type": "module" to your package.json, require Node.js 12, update docs & code examples, and do a major release.

Rip off the bandaid and completely move to JavaScript Modules.

There are two ways to handle the migration:Pure: Rip off the bandaid and completely move to JavaScript Modules.Dual: Introduce a build step that transpiles a CommonJS fallback.

After discussion with the team, we're going to avoid Request and Response in favour of POJOs, which are much less cumbersome.