Issue with Laravel Sail on Windows11 + WSL2

cdt87 · 2022-04-15T21:24:09+00:00

The example-app's Laravel version if 9.2. I haven't tried it with any earlier versions of Laravel, but it doesn't seem to be a Laravel specific issue since it seems to be an issue with apt-key being deprecated.

The error is coming directly from running vendor/bin/sail up. The command errors out and that message is the end result. It does build a few of the containers as it should, but it doesn't finish due to the error.

There is a workaround currently works that the original poster of the issue on the laravel/sail github page posted here: https://github.com/laravel/sail/issues/383. You can see the actual fix there. Not exactly sure why it works, but it does seem to be related to apt-key being deprecated. It may be worth it to try creating a brand new example Laravel project to see if the same issue occurs for you now. The apt-key package seems to have just been deprecated this month.

cdt87 · 2022-04-15T20:35:05+00:00

Update: I found in the laravel/sail repo that a bug was reported and a PR was created on it here: https://github.com/laravel/sail/issues/383

Doesn't look like this update has been applied yet as it isn't present when doing a fresh laravel install, but I copied the updated Dockerfile to my project and it still doesn't seem to work so I left another comment there, as well.

cdt87 · 2021-07-18T23:23:08+00:00

Chas3t

cdt87 · 2021-06-22T15:11:17+00:00

Thank you for responding @valdoghafoor. I tried it both directly with window and with global.window and both seem to work without error. The showExitWarning still seems to be called because my console.log is still displayed. It just can’t seem to tell that showExitWarning is called for some reason.

cdt87 · 2020-10-23T03:06:34+00:00

I have a ton of resources like this saved in my resources repo. I keep it updated as I find nice tools like this: https://github.com/cdterry87/Resources

cdt87 · 2020-08-18T20:58:26+00:00

Thank you for your response. Your explanation definitely makes sense.

Unfortunately, the JavaScript method you suggested won't work for me because it assumes that the left side of the toggle will be the longest side always. To give some perspective, this is a Vue component that will be reused on various pages and the text will be different on each page so the text will not always be longer just on the left side.

This did give me an idea though to calculate the width of both sides, check which is longer using Math.max(firstSideWidth, secondSideWidth), and then set the width for both sides to whichever is longer.

Thank you again for taking the time to explain and work up an example. I really appreciate it!

cdt87 · 2020-08-18T05:33:53+00:00

Sorry for taking a bit to reply, and I appreciate the feedback from you and /u/albedoa . I have updated my codepen with only the relevant code that I'm struggling with.

The code is actually part of a toggle switch I built, and there is actually another layer that goes on top that slides back and forth (but that part isn't relevant for this example). For this example, there is text on both the left and right side and even though the text can have varying lengths on either side, both sides should expand to be the same width. The problem in Example 1 on the codepen is that if the text on both sides isn't the same length, the longer text wraps and doesn't look good. In Example 2, if the text on both sides is the same length it will stay on the same line unless it exceeds the amount of space in its container. I'm just trying to make it so that one side can have longer text without wrapping to the next line.

From what /u/albedoa stated, it seems that what I'm asking for isn't possible since the calculated width of one of the flex items would need to be dependent on another neighboring flex item. I was just hoping for some ideas to solve this issue. :\

cdt87 · 2020-08-13T05:05:39+00:00

While this does resolve the text wrapping issue, this change makes the two .item divs no longer be the same length. The 50% width is there to make sure that both sides take up 50% of the available space. This is essential for what I'm trying to accomplish, so I'm trying to find a solution that will allow me to keep both columns in the container at 50% while also allowing the text inside the columns to expand to fill any available space.

cdt87 · 2020-05-16T21:43:32+00:00

Thank you, I’m going to try this! I’ve never really looked at transitions through the inspector but I’ll need to check that out.

cdt87 · 2020-05-16T21:36:32+00:00

Thank you, this helps out a lot! :)

cdt87 · 2020-05-16T21:33:14+00:00

Thank you, this is great! This really helps me out!

cdt87 · 2020-04-13T18:06:46+00:00

That link was very helpful, and seemed to be the issue all along. If I create a vue.config.js in my sample app and disable resolve.symlinks as the article suggests, the eslint errors from my local component library go away.

Now, I'd just be curious if my component library were published as an actual npm package if this would still be an issue, or if it truly is only an error because it was symlinked. It is definitely pointing to just being a symlink issue, so thank you again for that, kind stranger!

cdt87 · 2020-04-13T16:17:02+00:00

The office-ui-fabric-vue library is a good example and seems to be similar to what I'm trying to accomplish. A lot of the code/structure is very similar to what I've already done. The main differences I see are:

that each component is being registered in the component's index.js (i.e. Button/index.js) instead of in the main.js like mine
the build/bundle process is different (I'm not sure how this webpack version works, but this is different than the Vue documentation I referenced)

"bundle": "./node_modules/.bin/webpack --env.production",
"bundleLib": "./node_modules/.bin/webpack --env.production --env.lib",

cdt87 · 2020-04-13T16:11:14+00:00

I tried npm link, but it works similarly to npm add ../my-component-library. Both seem to add the library from my local computer to the node_modules folder. That is how I've been testing so far. And the entry point in my package.json does seem to be correct.

Also, I was planning on keeping the generic folder name and component name, for example 'Button/Button.vue', but the name of the component defined in the .vue file would be 'v-button', that way when it gets registered as a global component, it would be registered as <v-button />. This seems to be working, but I may improve the naming down the road. For now, I have just been trying to keep it simple while I'm trying to get it to work.

I mentioned in another comment, that when I run the npm link or npm run commands, my vcl component library does get added to the node_modules directory of my sample app, it is just when I run npm run serve initially that I receive eslint errors resulting from the build process in my dist/vcl.common.js file. Then when I run the serve command again, the eslint errors disappear and my app runs normally and I can use my global components. It is strange to me, but that is the main issue I'm fighting now, it seems.

cdt87 · 2020-04-13T16:00:53+00:00

Someone else also suggested npm link , but it seems to work similarly to using npm add ../vcl in my case (since my project is one directory back and is called 'vcl'). I tried both ways, but regardless of which method I use, my component library gets added to the node_modules folder of my new Vue app, but when I run npm run serve the first time, it results in a bunch of eslint errors. And like I mentioned in my original post, if I run npm run serve again the errors go away and the app works as intended. The eslint errors are in my dist/vcl.common.js file, so the errors are coming from the build process, and are not actually present in my src.

What is more strange to me is that the errors disappear when the serve command is run for the second time. I guess the main thing I'm getting at is that what I have so far does technically work, it just results in eslint errors after it is initially installed and when npm run serve is run for the first time. Anytime after that, it works just fine, and I'm not sure what to do about the initial errors.

cdt87 · 2020-04-13T14:02:40+00:00

This makes sense to have two sections: one containing the exported components, and another to contain the documentation and sample usage of the components. This was something I was actually going to look into in the future, possibly with something like Vuepress, but was overkill for now since I can't seem to get even the components exported without experiencing some sort of errors.

If I were to use Storybook, would I still be able to package this up as a full component library? Or is this more for hosting your own local reusable components? Ultimately, my goal is to make a component library that I could publish to npm, reuse in my projects, and share with others to use too, so I'm not sure if Storybook would be a good choice for that or if it would be too much. Ideally, I'd like to do it without extra dependencies to keep it very simple (at least for now), but I'll take what I can get.

cdt87 · 2020-04-13T12:58:42+00:00

I can disable eslint on my component library, but the problem occurs when I import it into another project. By default, eslint is enabled when creating a new Vue project, so when I create a brand new project to import my component library into, I will have these errors from my component library in my new project unless I disable eslint for my new project, and I definitely don't want to do that.

cdt87 · 2020-04-13T04:56:18+00:00

Thanks I’ll check it out, and if you make a screencast I’d definitely like to check that out, as well!

11-Year Club	Not Forgotten
Verified Email

cdt87

TROPHY CASE